Теневая ИИ-разработка: что делать, если команда использует ИИ без правил

Когда скорость разработки обгоняет контроль — и почему это уже не просто неудобство, а системный риск

Тихая революция, которую вы уже проморгали

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

Это не фантазия. Это рутина для большинства инженерных команд в 2025–2026 годах.

По данным Deloitte's 2026 State of AI in the Enterprise report, доступ сотрудников к ИИ вырос на 50% только за 2025 год — и лишь каждая пятая компания имеет зрелую модель управления этим процессом [5]. По данным McKinsey, 88% организаций используют ИИ хотя бы в одной бизнес-функции в 2025 году, против 78% в 2024-м и 55% в 2023-м [6].

Разрыв между скоростью адаптации и скоростью выстраивания governance — это и есть теневой ИИ в разработке. И он уже не про вопрос "есть ли у вас эта проблема". Он про вопрос "насколько глубоко она у вас зашла".

Эта статья — для CTO, VP Engineering, Tech Lead и AppSec-специалистов, которые хотят понять масштаб проблемы, её реальные риски и то, как выстроить работающий контроль без остановки команды.

Что такое теневой ИИ в разработке

Теневой ИИ — это использование ИИ-инструментов сотрудниками без одобрения IT- или security-отдела. Термин вошёл в обиход в 2023–2024 годах как развитие концепции shadow IT, но несёт принципиально иные риски [7].

Если теневое IT означало "команда завела Trello без согласования", то теневой ИИ означает "команда ежедневно передаёт корпоративные данные во внешние модели, которые могут их использовать для дообучения".

Разница критическая. Данные в Trello — это данные в хранилище. Данные, отправленные в публичный LLM — это данные, которые вы уже не контролируете.

В контексте разработки теневой ИИ выглядит так:

1. Разработчик вставляет фрагмент бизнес-логики в ChatGPT, чтобы получить объяснение или рефакторинг.
2. Инженер использует Cursor или другой AI-ассистент под личным аккаунтом, а не корпоративной лицензией.
3. Тимлид настраивает интеграцию с внешним LLM-API напрямую в CI/CD-пайплайне, минуя security-ревью.
4. Команда бэкенда использует один инструмент, фронтенд — другой, инфра — третий, и никто об этом не договаривался.
5. Разработчик устанавливает браузерное расширение с ИИ-функциями, которое получает доступ ко всем открытым вкладкам — включая внутренние системы.

По данным IBM, более 37% сотрудников в 2025 году признают использование теневого ИИ на рабочем месте [8]. По данным IDC, 56% сотрудников используют несанкционированные ИИ-инструменты против 23%, использующих только официально одобренные [9].

Почему это происходит: экономика теневого ИИ

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

GitHub зафиксировал в 2024 году ускорение выполнения задач разработчиками с ИИ-ассистентами на 55% по сравнению с теми, кто их не использует [1]. При таком разрыве в производительности отказываться от инструмента ради ожидания корпоративного согласования — значит добровольно работать хуже конкурентов.

Три главные причины появления теневого ИИ в командах:

Скорость. Официальный процесс согласования нового инструмента занимает недели или месяцы. Нужный ответ от ChatGPT — секунды. Это не вопрос дисциплины, это вопрос экономики времени.

Доступность. Мощные публичные модели бесплатны или стоят несколько долларов в месяц. Процесс выбора и закупки корпоративной альтернативы сложен и непрозрачен.

Отсутствие ориентиров. По данным исследования Harmonic Security, только 55% компаний имеют формальные политики использования ИИ [10]. Там, где нет явного запрета или явного разрешения, люди трактуют ситуацию как "разрешено по умолчанию".

Именно поэтому стратегия тотального запрета не работает. Netskope в 2025 году зафиксировал, что 60% пользователей продолжают использовать заблокированные GenAI-приложения через личные аккаунты [4]. Запрет не устраняет поведение — он только делает его невидимым.

Реальные риски: не теория, а задокументированные инциденты

Кейс Samsung: три утечки за 20 дней

В марте 2023 года Samsung разрешил инженерам полупроводникового подразделения использовать ChatGPT для работы. Менее чем за 20 дней произошло три отдельных инцидента:

• Инженер вставил проприетарный исходный код в чат, чтобы ChatGPT нашёл баги.
• Другой разработчик загрузил код тестовой последовательности для микрочипов, запросив оптимизацию.
• Третий записал внутреннее совещание, транскрибировал запись и попросил ChatGPT сделать протокол встречи [3].

Итог: код с критически важными деталями о производственных процессах и контроле качества оказался на серверах OpenAI. Samsung немедленно запретил использование ChatGPT на всех корпоративных устройствах и объявил о разработке собственной внутренней модели.

Все три инцидента совершили высококвалифицированные инженеры, действовавшие добросовестно и стремившиеся работать эффективнее.

Масштаб проблемы в цифрах

По данным Cyberhaven, с марта 2023 по март 2024 объём корпоративных данных, вставляемых в ИИ-инструменты, вырос на 485%. Из общего объёма передаваемых чувствительных данных 12,7% составляет исходный код и 10,8% — R&D-материалы [11].

IBM в отчёте Cost of Data Breach 2025 зафиксировал: инциденты, связанные с теневым ИИ, обходятся компаниям в среднем на $670 000 дороже обычных инцидентов. 97% взломанных организаций не имели на момент инцидента надлежащего контроля доступа к ИИ [9].

По данным Gartner, к 2027 году 75% сотрудников будут приобретать, модифицировать или создавать технологии вне видимости IT-отдела [12].

Проблема "работает" ≠ "безопасно"

Параллельно с риском утечек данных существует системный риск качества кода. Veracode в 2025 году протестировал более 100 LLM на 80 задачах по написанию кода и выяснил: 45% сгенерированного ИИ кода содержит уязвимости из OWASP Top 10 [2].

Java показал наихудший результат — 72% failure rate. Cross-Site Scripting (CWE-80) демонстрировал 86% failure rate. При этом ключевой вывод отчёта: увеличение размера модели не улучшает безопасность. Это системная проблема, а не проблема конкретного инструмента.

Независимое исследование Apiiro по репозиториям компаний из Fortune 50 показало: у разработчиков, использующих ИИ-ассистенты, в 2,5 раза больше уязвимостей с CVSS ≥ 7.0, на 322% больше путей эскалации привилегий и на 40% больше случаев экспозиции секретов в коде [13].

По данным той же Apiiro, к июню 2025 года AI-сгенерированный код добавлял более 10 000 новых security-findings ежемесячно в отслеживаемых репозиториях — это рост в 10 раз относительно декабря 2024 года [13].

При этом разработчики с ИИ создают в 3–4 раза больше коммитов. Скорость растёт. Но число инцидентов на pull request растёт быстрее скорости — на 23,5% год к году [13].

Специфический риск: IP и юрисдикция

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

• использоваться для дообучения модели;
• обрабатываться в дата-центрах за пределами юрисдикции компании;
• быть потенциально доступны другим пользователям через "утечки" контекста.

Без Data Processing Agreement (DPA) с вендором у организации нет договорных гарантий того, что её код является её кодом.

Почему теневой ИИ — это не проблема ИБ. Это проблема управления

Распространённая ошибка — передавать тему теневого ИИ в зону ответственности security-команды и ждать от неё технического решения. Это необходимо, но недостаточно.

Теневой ИИ возникает там, где между реальными рабочими практиками и официальной инфраструктурой образуется разрыв [6]. Security-контроль закрывает этот разрыв силой. Governance — устраняет причину его появления.

По данным McKinsey, компании с зрелой AI governance демонстрируют более высокий ROI от AI-внедрений, чем те, кто занимался только техническим контролем. Связано это с тем, что плохой governance порождает два параллельных потока: официальный медленный и неофициальный быстрый, и производительность системы определяет именно второй [6].

Для инженерных команд в России и СНГ актуален ещё один слой: в 2025 году российский рынок ИБ зафиксировал новый тип риска — утечки через ИИ-модели, связанные с передачей корпоративной информации в зарубежные системы без понимания условий обработки данных. По данным анализа Habr/SecuriTM, бизнес внедряет ИИ быстрее, чем службы ИБ успевают обеспечить контроль, и даже компании, официально не использующие ИИ в продуктах, сталкиваются с тем, что каждый сотрудник это делает через сторонние сервисы [14].

Как выстроить управление теневым ИИ: пошаговый фреймворк

Шаг 1: Аудит текущего состояния (прежде чем вводить правила)

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

Что делать:

1. Провести анонимный опрос команды: какие ИИ-инструменты используются, для каких задач, насколько часто.
2. Проанализировать сетевой трафик на предмет обращений к известным LLM API-эндпоинтам.
3. Изучить установленные расширения в браузерах на корпоративных устройствах.
4. Проверить IDE плагины и их разрешения.
5. Проверить, какие внешние API вызываются из CI/CD-пайплайнов.

Цель аудита — не наказать нарушителей, а составить реальную карту использования.

Шаг 2: Трёхуровневая классификация инструментов

Наиболее эффективным подходом в 2025–2026 годах стала система "светофора" для ИИ-инструментов [15]:

Зелёный уровень (одобрено). Корпоративные лицензии с DPA, нулевым хранением данных и полным логированием. Примеры: GitHub Copilot Enterprise, Tabnine Enterprise self-hosted, одобренные внутренние модели. Для этого уровня — минимальные ограничения.

Жёлтый уровень (условно разрешено). Инструменты, прошедшие security-ревью, но с ограничениями на типы данных. Например: нельзя передавать код с секретами, логинами, конфигурациями production-окружения или данными клиентов.

Красный уровень (запрещено). Публичные инструменты без DPA, инструменты с неопределёнными условиями хранения данных, любые инструменты с правом использования ввода для обучения без отказа.

Ключевое правило: политика должна быть про данные, а не только про инструменты. Один и тот же ChatGPT может быть "жёлтым" для обсуждения архитектуры в общих чертах и "красным" для вставки production-кода.

Шаг 3: Защита критически важных данных

Определите классификацию данных применительно к ИИ:

1. Данные, которые нельзя передавать ни в какой внешний ИИ: API-ключи и секреты; production credentials и конфигурации; исходный код ключевых компонентов с бизнес-логикой; персональные данные пользователей; финансовые данные.
2. Данные, которые можно передавать в "жёлтые" инструменты с ограничениями: архитектурные концепции (в общем виде); документация; тестовые данные и синтетические примеры.
3. Данные, которые можно передавать в одобренные инструменты: публичный код; общие технические вопросы; задачи без привязки к конкретной инфраструктуре.

По данным NIST AI RMF, центральный элемент зрелого AI governance — разграничение ответственности между бизнес-лидерами, инженерами, юридической службой и командой безопасности через чёткие роли и политики [16].

Шаг 4: Контроль на уровне PR и релиза

Самая уязвимая точка в AI-assisted разработке — это merge. Код, написанный с ИИ, попадает в репозиторий через pull request, который зачастую не дочитывают до конца — особенно если он большой и "очевидно рабочий".

Задача security-слоя на этапе PR: проверить не только что написано, но и как это влияет на всё остальное.

Что проверять перед merge AI-сгенерированного кода:

1. Наличие новых зависимостей и их advisory-статус.
2. Новые конфигурационные файлы или изменения в существующих.
3. Изменения в переменных окружения, секретах, ключах.
4. Расширение CORS, прав доступа, привилегий.
5. Изменения в CI/CD-файлах и pipeline-конфигурациях.
6. Использование устаревших или небезопасных библиотечных функций.
7. Новые API-интеграции и их source of trust.

Контроль изменений должен быть автоматизирован. Human review необходим, но ревьюер не может удерживать в голове полный контекст репозитория. Именно здесь помогает дополнительный слой анализа конкретного изменения в контексте всего кодовой базы.

HighVibe решает именно эту задачу: анализирует конкретный PR — изменения в коде, конфигурации, зависимостях — и даёт команде короткий сигнал до merge: что здесь действительно критично, а что можно принять. Не длинный security-отчёт, а ответ на конкретный вопрос — можно ли безопасно принять это изменение сейчас.

Шаг 5: Процесс легализации новых инструментов

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

Практический формат:

1. Разработчик заполняет короткую форму: инструмент, задача, тип данных, которые планируется передавать.
2. Security-команда проводит базовый ревью в течение 3–5 рабочих дней.
3. Инструмент получает статус зелёного/жёлтого/красного с конкретными ограничениями.
4. Решение документируется и становится общедоступным.

Такой "реестр одобренных инструментов" снижает количество теневых запросов, потому что у команды появляется легальный и быстрый путь [15].

Шаг 6: Обучение, а не только ограничения

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

Минимальная программа AI literacy для разработчиков:

1. Как работает retention policy в публичных LLM: что OpenAI, Anthropic, Google делают с данными по умолчанию.
2. Что считается чувствительными данными применительно к ИИ-инструментам.
3. Почему "работает" не значит "безопасно" — с примерами уязвимостей в AI-коде.
4. Как использовать одобренные инструменты с максимальной эффективностью.

Типичные ошибки при работе с теневым ИИ

Тотальный запрет вместо governance. Запрет создаёт иллюзию безопасности и выталкивает использование в зону, где у компании нет никакой видимости. По данным Netskope, 72% использования GenAI в корпоративной среде происходит через личные аккаунты [4].

Политика без enforcement. Документ с правилами, который не поддержан техническими контролями (мониторинг, CI/CD проверки, правила в прокси), — это просто документ. Разработчики работают в условиях дедлайнов, и без технических ограничений они будут принимать решения ситуативно.

Единая политика для всех ролей. Маркетолог, пишущий текст для лендинга с помощью ChatGPT, и разработчик, вставляющий в тот же ChatGPT production-код — это принципиально разные риски. По данным рекомендаций NIST AI RMF Generative AI Profile, политики должны быть дифференцированы по типам данных и ролям [16].

Игнорирование зависимостей и supply chain. ИИ-ассистенты регулярно "галлюцинируют" пакеты — предлагают зависимости с несуществующими или несовпадающими именами. Такие пакеты могут содержать вредоносный код. По данным Apiiro, в среде AI-assisted разработки случаи "package hallucination" участились [13]. Lock-файлы и проверка advisories для каждой новой зависимости — обязательный элемент контроля.

Игнорирование конфигов, IaC и служебных файлов. Именно эти файлы читают хуже всего при code review. ИИ, написавший изменение в Dockerfile, terraform-конфигурации или CI/CD-файле, может добавить небезопасные дефолты, расширенные права или debug-режим, который никто не заметит до production-инцидента.

Инструменты: что реально помогает

Технические решения работают в связке с governance, а не вместо него. Полезные категории инструментов:

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

Proxy-прослойка между разработчиком и LLM. Позволяет логировать, фильтровать и инспектировать запросы к внешним моделям в реальном времени. Ключевой элемент архитектуры для компаний, которые хотят видеть, что происходит, не запрещая инструменты полностью [17].

SAST и SCA в CI/CD. Статический анализ кода обнаруживает характерные для AI-генерации паттерны уязвимостей. Анализ зависимостей отслеживает новые пакеты. Это не замена полноценного review, но необходимый baseline.

Анализ изменений перед merge. Именно здесь находится наиболее острая практическая точка для AI-assisted разработки: большой PR, сгенерированный с ИИ, требует не просто code review, а контекстного анализа того, что изменилось в связке с тем, как это связано с остальным кодом, зависимостями и конфигурациями. HighVibe работает именно в этой точке — анализирует конкретное изменение и дающий команде ясный ответ до merge и релиза.

Реестр ИИ-инструментов с учётом usage. Платформы вроде Zylo, Reco и аналогичных дают visibility по тому, какие SaaS AI-инструменты реально используются в организации, включая несанкционированные.

Регуляторный контекст: стандарты и требования

Теневой ИИ создаёт не только операционные, но и compliance-риски.

NIST AI RMF 1.0 (2023) с Generative AI Profile (июль 2024) — основной добровольный фреймворк, на который ориентируются организации при выстраивании AI governance. Четыре функции: Govern, Map, Measure, Manage. Функция Govern напрямую предполагает создание и соблюдение политик использования ИИ [16].

ISO/IEC 42001:2023 — международный стандарт системы менеджмента ИИ. Сертификация по нему становится рыночным требованием для enterprise-контрактов. В России активно ведётся работа по стандартизации через технический комитет ТК 164 (ИИ) [18].

SOC 2 и ISO 27001 требуют от организаций ведения реестра систем, обрабатывающих чувствительные данные. Если ИИ-инструменты используются за пределами видимости IT-отдела, этот реестр неполон — и это прямое нарушение compliance-требований [15].

GDPR и ФЗ-152 (Россия). Передача персональных данных или данных, позволяющих идентифицировать субъектов, в зарубежные ИИ-системы без надлежащих правовых оснований — потенциальное нарушение требований к трансграничной передаче данных.

Будущее: агентный ИИ делает ставки выше

До 2025 года теневой ИИ означал "разработчик вставил код в чат". В 2026 году риск качественно изменился.

Агентные ИИ-системы — такие как OpenClaw (135 000 звёзд на GitHub на начало 2026 года) — не просто отвечают на запросы, они принимают действия: создают pull requests, изменяют файлы, вызывают внешние API, интегрируются со Slack и Google Workspace. Когда разработчик подключает такого агента к корпоративным системам через личный аккаунт, создаётся теневой ИИ с elevated privileges, которые традиционные security-инструменты не видят [19].

По данным Reco AI, в 2025 году был зафиксирован инцидент, в котором угрозы-актор UNC6395 использовал скомпрометированные OAuth-токены от Drift Salesforce-интеграции для доступа к среде клиентов более чем 700 организаций [19].

Prognosis неутешителен: Gartner предсказывает, что к 2030 году более 40% предприятий столкнутся с security- или compliance-инцидентами, связанными с неавторизованным теневым ИИ [13].

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

Чек-лист: что проверить прямо сейчас

Аудит текущего состояния:

• Провели ли вы опрос команды о реально используемых ИИ-инструментах?
• Есть ли у вас список одобренных инструментов с указанием допустимого типа данных?
• Проверяли ли вы логи прокси и DNS на предмет обращений к LLM API?

Политика и документация:

• Есть ли у вас письменная политика использования ИИ-инструментов?
• Есть ли у вас DPA с каждым вендором в вашем "зелёном" списке?
• Классифицированы ли данные с точки зрения допустимости передачи в ИИ?

Контроль на уровне кода:

• Настроен ли SAST-сканер на CI для AI-типичных уязвимостей?
• Проверяются ли все новые зависимости в PR на advisory и package integrity?
• Есть ли у вас контроль изменений в конфигах, IaC, CI/CD-файлах до merge?
• Читает ли ваша команда PR с AI-кодом до конца, или останавливается на том, что "работает"?

Обучение и культура:

• Знают ли разработчики, как работает data retention в публичных LLM?
• Понимают ли они, что "код работает" ≠ "код безопасен к merge"?
• Есть ли быстрый легальный путь запросить одобрение нового инструмента?

Заключение: не запрещать, а управлять

Теневой ИИ — это не проблема дисциплины. Это проблема отставания governance от скорости адоптации технологий.

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

Правильный ответ выглядит так: дать команде легальные, быстрые и удобные инструменты с чёткими правилами; выстроить контроль на уровне изменений — в PR, зависимостях, конфигурациях, перед релизом; сделать риск видимым, прежде чем он станет инцидентом.

В 2026 году вопрос не в том, использует ли ваша команда ИИ. Вопрос в том: вы знаете, какой ИИ-инструмент прямо сейчас попадает в ваш репозиторий? И что именно он туда несёт?

Если нет — это отправная точка.

Источники

[1] Plain English — "The Hidden Rise of Shadow AI and Why Developers Can't Ignore It" — https://plainenglish.io/artificial-intelligence/the-hidden-rise-of-shadow-ai-and-why-developers-can-t-ignore-it

[2] Veracode — "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests." — https://www.veracode.com/blog/genai-code-security-report/

[3] AI Incident Database — "Incident 768: ChatGPT Implicated in Samsung Data Leak of Source Code and Meeting Notes" — https://incidentdatabase.ai/cite/768/

[4] Netskope — данные о доле пользователей, использующих заблокированные GenAI-инструменты через личные аккаунты; цитируется в: Skywork AI — "Shadow AI: Why 37% of Employees Are a 2025 Security Threat" — https://skywork.ai/blog/shadow-ai-corporate-security-threat-2025/

[5] Wiz — "What is Shadow AI? Why It's a Threat and How to Embrace and Manage It" (Deloitte 2026 State of AI in the Enterprise) — https://www.wiz.io/academy/ai-security/shadow-ai

[6] Chronus — "Shadow AI Is a Symptom of Isolation. Here's How to Avoid It." (McKinsey 2025 State of AI) — https://chronus.com/blog/shadow-ai-is-a-symptom-of-isolation-heres-how-to-avoid-it

[7] HRKatha — "The shadow AI workforce: When employees go rogue with tech" — https://www.hrkatha.com/features/hr-pops-features/the-shadow-ai-workforce-when-employees-go-rogue-with-technology/

[8] IBM — "What Is Shadow AI?" — https://www.ibm.com/think/topics/shadow-ai

[9] SentinelOne — "What is Shadow AI? Definition, Risks & Governance Strategies" (IBM Cost of Data Breach 2025, IDC 2025) — https://www.sentinelone.com/cybersecurity-101/cybersecurity/what-is-shadow-ai/

[10] Worklytics — "Shadow AI in 2025: Detecting Unauthorized Tool Use Without Violating GDPR" (Harmonic Security data) — https://www.worklytics.co/resources/shadow-ai-detection-gdpr-compliance-2025

[11] Cyberhaven — данные о росте корпоративных данных в ИИ-инструментах; цитируется в: Skywork AI — https://skywork.ai/blog/shadow-ai-corporate-security-threat-2025/

[12] Gartner — прогноз о 75% сотрудников, приобретающих технологии вне IT-видимости к 2027 году; цитируется в: F5 — "Shadow AI: The Silent Security Risk Lurking in Your Enterprise" — https://www.f5.com/company/blog/shadow-ai-the-silent-security-risk-lurking-in-your-enterprise

[13] Apiiro / SoftwareSeni — "AI-Generated Code Security Risks: Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[14] Habr / SecuriTM — "Рынок ИБ в России: тренды и перспективы" — https://habr.com/ru/companies/securitm/articles/975772/

[15] Larridin / Zylo — "AI Governance: The Complete Enterprise Guide 2026" / "Shadow AI: Causes, Consequences, and Best Practices for Control" — https://larridin.com/solutions/ai-governance-the-complete-enterprise-guide-2026 / https://zylo.com/blog/shadow-ai

[16] NIST — "AI Risk Management Framework: Generative AI Profile" (July 2024) — https://www.nist.gov/artificial-intelligence/ai-risk-management-framework

[17] CIO.com — "Shadow AI morphs into shadow operations" — https://www.cio.com/article/4162664/shadow-ai-morphs-into-shadow-operations.html

[18] Habr / SecurityVision — "Кибербезопасность ИИ. Часть 3. Регулирование, стандартизация и кибербезопасность ИИ" — https://habr.com/ru/companies/securityvison/articles/1009462/

[19] Reco AI — "AI & Cloud Security Breaches: 2025 Year in Review" — https://www.reco.ai/blog/ai-and-cloud-security-breaches-2025