Политика использования ИИ в разработке: что разрешить, что запретить, что проверять

Практическое руководство для CTO, Tech Lead и AppSec-команд, которые уже ускорились с ИИ, но не успели выстроить контроль

Скорость ускорилась, контроль — нет

В 2025 году 84% разработчиков используют или планируют использовать ИИ-инструменты для написания кода [1]. По данным аналитики Stack Overflow Developer Survey 2025, 51% делают это ежедневно [4]. На GitHub Copilot приходится более 20 миллионов пользователей, инструмент применяется в 90% компаний из Fortune 100 [5].

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

Рабочий pull request не означает безопасный. Дифы читают не до конца, новая транзитивная зависимость приезжает незаметно, конфиги и миграции изучают поверхностно. А ИИ тем временем генерирует сотни строк за минуты, и команда физически не успевает проверить каждую.

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

Часть 1. Почему «запретить всё» не работает

Первая реакция безопасников на новый инструмент — запрет. С ИИ-ассистентами эта стратегия не срабатывает по нескольким причинам.

Во-первых, инструменты уже внутри. Cursor, GitHub Copilot, Claude Code и их аналоги встроены в IDE — разработчики начинают использовать их ещё до появления официальной политики. По данным IBM X-Force 2025, «теневые» ИИ-инструменты без политики видимости фигурируют в 20% расследованных инцидентов [6].

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

В-третьих, потеря конкурентоспособности. Команды, которые умеют безопасно использовать ИИ-инструменты, объективно быстрее тех, кто их запрещает.

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

Часть 2. Реальные риски: что именно идёт не так

Прежде чем формулировать политику, важно понимать конкретные векторы угроз. Они делятся на четыре категории.

2.1 Уязвимый код по умолчанию

ИИ-модели обучаются на огромных корпусах публичного кода — включая небезопасные туториалы, скопированные SO-ответы и устаревшие паттерны. Результат: сгенерированный код воспроизводит известные уязвимости.

Эмпирическое исследование 2024 года выявило уязвимости примерно в 30% фрагментов кода, сгенерированных GitHub Copilot, по 43 категориям CWE [2]. Наиболее частые: SQL-инъекции (CWE-89), внедрение команд ОС (CWE-78), внедрение кода (CWE-94), захардкоженные учётные данные (CWE-259/798) [7]. Четыре из пяти вошли в MITRE Top 25 Most Dangerous Software Weaknesses 2024 [7].

Анализ Veracode 2025 показал, что ИИ-генерированный код содержит уязвимости в 45% случаев на выборке из 80 реальных задач для более чем 100 моделей [8].

Характерная проблема: разработчики, использующие ИИ-ассистенты, чаще уверены в корректности своего кода, чем те, кто пишет вручную — даже когда в нём есть уязвимости [9]. Эффект ложной уверенности.

По данным исследования 2025 года, показатель доверия к точности ИИ-результатов среди разработчиков упал с 40% до 29% год к году — скептицизм растёт, но проверки не успевают за объёмом генерации [1].

2.2 Утечка секретов и проприетарного кода

GitGuardian State of Secrets Sprawl 2026 зафиксировал 28,65 миллиона новых захардкоженных секретов в публичных репозиториях GitHub за 2025 год — рост на 34%, крупнейший прирост за историю наблюдений [3]. Утечки учётных данных AI-сервисов выросли на 81%.

Репозитории, использующие GitHub Copilot, имеют примерно вдвое более высокий показатель утечки секретов по сравнению с базовым уровнем: 3,2% против 1,5% в AI-assisted коммитах [3].

Другой аспект — промпты разработчиков содержат фрагменты проприетарного кода, ключи API, внутренние имена переменных и структуры данных [10]. Отправляя эти данные в облачный LLM, команда де-факто передаёт интеллектуальную собственность третьей стороне с неясными условиями хранения и обучения.

2.3 Галлюцинированные зависимости и slopsquatting

Исследование марта 2025 года (576 000 образцов кода для 16 LLM-моделей) показало: около 19,7% рекомендованных пакетов — 440 445 штук — не существуют [11]. У коммерческих моделей этот показатель составляет около 5%, у открытых — до 22%.

Атака называется slopsquatting: злоумышленник регистрирует пакет с именем, которое ИИ стабильно «галлюцинирует» — таких стабильно повторяющихся несуществующих имён 43% от всего набора. Следующий разработчик, получивший тот же совет от ИИ, установит уже вредоносный пакет [12].

В 2025 году в реестрах пакетов было опубликовано 454 648 вредоносных пакетов, по данным Socket mid-year threat report [13]. Более 99% целились в npm. Часть из них была создана с помощью автоматизации на базе ИИ.

2.4 Prompt injection и атаки через конфиг-файлы

В 2025 году исследователи обнаружили, что злоумышленники могут встраивать вредоносные инструкции в конфигурационные файлы, используемые Cursor и GitHub Copilot, заставляя инструмент незаметно генерировать код с бэкдорами [14]. GitHub в мае 2025 добавил предупреждение о скрытом Unicode-тексте — но сама уязвимость устранена лишь частично.

Исследователи из Pillar Security описали полный цикл атаки: заражённый конфиг-файл переопределяет защитные настройки, и ИИ начинает генерировать код, обходящий security-проверки [14]. Это атака не на разработчика, а на сам инструмент, которому разработчик доверяет.

Часть 3. Принципы построения политики

Прежде чем переходить к спискам запрещённого и разрешённого, полезно зафиксировать несколько принципов.

Политика должна быть технически enforceable. Правило, которое существует только в документе, не работает. Каждое значимое ограничение должно иметь технический контрол — gate в CI/CD, hook, правило в SAST.

Разработчик, который коммитит код, несёт ответственность за него — независимо от того, кто его написал: человек или ИИ. Это «золотое правило» фигурирует в большинстве зрелых политик [15]. ИИ — инструмент, не автор.

Политика должна работать на уровне изменения, а не всего репозитория. Разумный вопрос перед merge — не «насколько безопасен весь кодовый репозиторий», а «безопасно ли принять конкретно это изменение прямо сейчас».

Не весь код одинаково критичен. Автоматизация тестов и документации — один уровень риска. Модули аутентификации, обработка платежей, криптография — другой. Политика должна это учитывать.

Shadow AI хуже, чем управляемое использование. Чрезмерно ограничительная политика порождает нелегальное использование — без видимости и без контроля.

Часть 4. Что разрешить

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

4.1 Сценарии с низким риском: разрешить с минимальными ограничениями

• Генерация boilerplate-кода и шаблонных структур.
• Написание и рефакторинг unit-тестов и интеграционных тестов.
• Генерация документации, комментариев, README.
• Автодополнение в IDE для синтаксиса, очевидной логики, стандартных паттернов.
• Помощь с регулярными выражениями, форматированием, поиском ошибок без вставки проприетарного контекста.
• Рефакторинг вспомогательного кода под наблюдением разработчика.
• Прототипирование и исследовательский код вне production-репозитория.

4.2 Сценарии с повышенным вниманием: разрешить с обязательным человеческим ревью

• Реализация бизнес-логики в production-компонентах.
• Работа с внешними API и интеграциями.
• Конфигурационные файлы инфраструктуры (Terraform, Kubernetes manifests, Docker).
• Миграции баз данных.
• CI/CD-скрипты и pipeline-конфигурации.
• Служебный код для internal tools.

4.3 Одобренные инструменты

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

1. Название инструмента и версия/тариф (например, GitHub Copilot Business).
2. Разрешённые сценарии использования.
3. Ограничения (что нельзя вставлять в промпты — секреты, PII, имена клиентов, внутренние переменные).
4. Условия хранения данных у провайдера — проверить data retention policy.
5. Статус: одобрен / одобрен с ограничениями / под ревью / запрещён.

Любой инструмент, не вошедший в список одобренных, по умолчанию запрещён. Это закрывает проблему shadow AI на уровне политики — техническое enforcement добавляется отдельно через мониторинг сети или endpoint-агентов.

Часть 5. Что запретить

5.1 Абсолютные запреты

Следующие действия должны быть запрещены безусловно, независимо от контекста:

• Вставка в промпты любых секретов: ключей API, токенов, паролей, client secrets, сертификатов.
• Вставка персональных данных пользователей: имён, email, телефонов, платёжных данных — в любом виде.
• Передача исходного кода модулей аутентификации, шифрования, управления доступом в внешние облачные LLM без корпоративного контракта с гарантиями no-training.
• Использование ИИ-генерированного кода в security-critical компонентах (auth, криптография, платежи) без обязательного human review и SAST-прогона.
• Автоматический merge кода, сгенерированного ИИ-агентом, без проверки человеком.
• Использование неодобренных инструментов с доступом к production-репозиториям.
• Коммиты конфигурационных файлов ИИ-инструментов (.cursorrules, .github/copilot-instructions.md) без ревью — именно через них реализуется атака Rules File Backdoor [14].

5.2 Контекстные запреты

Дополнительные ограничения для специфических контекстов:

• В медицинских, финансовых и государственных системах: без явного согласования с AppSec — запрет использования облачных ИИ-инструментов для любого кода, обрабатывающего персональные данные или финансовые операции.
• В open-source проектах компании: отдельная политика на предмет лицензионной чистоты кода, который ИИ мог воспроизвести из обучающих данных.
• В агентных сценариях (AI-агент имеет доступ к репозиторию и выполняет автономные задачи): агент должен иметь отдельный идентификатор, минимальные права (принцип least privilege) и все его действия должны быть атрибутируемы и обратимы [16].

Часть 6. Что проверять

Здесь начинается операционная часть политики — то, что реально влияет на безопасность.

6.1 До написания кода: настройка инструмента

• Проверить data retention policy провайдера ИИ-инструмента: по умолчанию ли данные из промптов используются для дообучения модели.
• Настроить system prompt / instructions файл для корпоративного использования: явно указать следование OWASP Top 10, запрет на предложение небезопасных паттернов, использование внутренних библиотек там, где они есть. OpenSSF опубликовал практическое руководство по security-focused инструкциям для ИИ-ассистентов [17].
• Убедиться, что конфиг-файлы ИИ-инструментов в репозитории (.cursorrules, .github/copilot-instructions.md, .claude/settings) проходят ревью как любой другой код.
• Настроить классификацию данных: что можно, а что нельзя вставлять в промпты, исходя из уровня конфиденциальности кода. Руководство EDPB 2025 по AI Privacy предлагает критерии классификации [18].

6.2 До merge: проверки в PR

Это ключевой контрольный пункт. Рабочий pull request не обязательно безопасен.

Автоматические проверки (gates):

1. SAST-сканирование диффа — особенно важно для кода, помеченного как AI-generated. Инструменты: Semgrep, CodeQL, SonarQube, Checkmarx. OWASP и NIST SSDF рекомендуют встраивать SAST на уровне CI/CD как обязательный gate [19, 20].
2. Сканирование секретов — выявить API-ключи, токены, хеши паролей, connection strings в диффе. Инструменты: GitGuardian, Gitleaks, truffleHog.
3. SCA (Software Composition Analysis) — проверить каждую новую зависимость: существует ли она, нет ли open CVE, какая у неё лицензия. Это закрывает риск slopsquatting и атак через supply chain.
4. Проверка lock-файлов — убедиться, что lock-файл (package-lock.json, poetry.lock, go.sum) обновлён консистентно с manifest-файлом. Рассинхронизация — частый признак проблемы.
5. Проверка конфиг-файлов ИИ-инструментов на наличие hidden unicode, нетипичных инструкций или переопределения security-политик.

Человеческое ревью:

Автоматика не заменяет его — она помогает сосредоточить внимание ревьюера.

• Ревьюер обязан дочитать диф до конца (устранить «LGTM-рефлекс») [21].
• Особое внимание: изменения в модулях аутентификации, управления доступом, обработки входных данных.
• Для security-critical компонентов — обязательный senior developer review или AppSec-ревью.
• Флаги для эскалации: неожиданная новая зависимость, изменение конфига безопасности, debug-режим или расширенный CORS в production-ветке.

6.3 До релиза: финальный gate

Перед выходом в production команде нужен короткий ответ: «что действительно блокирует выпуск», а не ещё один длинный отчёт.

Что проверять:

1. Все критические и высокие уязвимости из SAST/SCA закрыты или имеют accepted risk с обоснованием.
2. Нет незакрытых секретов в новом коде.
3. Все новые зависимости верифицированы: существуют в реестре, нет open CVE, лицензия совместима.
4. Debug-настройки, тестовые ключи, расширенный CORS не попали в релизную ветку.
5. Конфиги ИИ-инструментов в репозитории прошли ревью.

6.4 Мониторинг после релиза

Некоторые проблемы проявляются не сразу. Рекомендации:

• Отслеживать AI-генерированный код в production минимум 30 дней после merge — технический долг от AI-кода часто проявляется через несколько недель [21].
• Настроить alert на появление новых CVE для зависимостей, которые уже в production.
• Измерять показатели качества AI-кода отдельно от человеческого: Change Failure Rate, количество post-release уязвимостей, технический долг — чтобы корректировать политику на основе данных.

Часть 7. Compliance и регуляторный контекст

7.1 Международный контекст

NIST выпустил SP 800-218A — «Secure Software Development Practices for Generative AI and Dual-Use Foundation Models», расширение SSDF специально для ИИ-разработки [20]. Это практическая основа для построения корпоративного процесса.

OpenSSF (Open Source Security Foundation) опубликовал «Security-Focused Guide for AI Code Assistant Instructions» [17] — набор рекомендаций по настройке system prompt для корпоративных ИИ-ассистентов.

EU AI Act: с февраля 2025 года применяются запреты на высокорисковые практики, с августа 2025 — требования для моделей общего назначения [22]. Это затрагивает компании, которые разрабатывают ПО для европейского рынка или используют ИИ-сервисы европейских провайдеров.

OWASP Top 10 для LLM Applications (2025) поставил Prompt Injection на первое место [12] — это формализация угрозы, описанной в разделе 2.4.

ISO 42001:2023 — первый международный стандарт для систем менеджмента ИИ. Добавляет 38 ИИ-специфических контролей и интегрируется с ISO 27001 [8].

7.2 Российский контекст

В России единый закон об ИИ находится в разработке, но регуляторная база уже начала формироваться:

• ФЗ-233 (август 2024) установил правила обработки персональных данных при использовании ИИ-систем [23]. Это напрямую касается использования облачных LLM для обработки кода, содержащего ПДн.
• ГОСТ Р 71657-2024 регламентирует использование ИИ в научной деятельности. Становится де-факто обязательным при участии в государственных закупках [24].
• Приказ ФСТЭК № 117 (апрель 2025) установил требования к защите информации в государственных информационных системах при использовании ИИ [25].
• Минцифры разрабатывает реестр «доверенного ИИ» для критической инфраструктуры (по состоянию на начало 2026 года — в процессе) [26].
• Обсуждается законопроект о классификации ИИ-систем по уровню риска (неприемлемый / высокий / ограниченный / минимальный) с запретом разработки систем «неприемлемого» уровня [27].

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

Часть 8. Как выглядит работающая политика

Политика должна состоять из двух частей: документа и технических контролей.

8.1 Структура документа

1. Область применения: на кого распространяется, какие инструменты и процессы охватывает.
2. Одобренные инструменты с условиями использования.
3. Классификация сценариев: низкий риск / повышенное внимание / запрет.
4. Список запрещённых действий (абсолютные и контекстные запреты).
5. Обязательные проверки в PR, до релиза, при использовании агентных сценариев.
6. Ответственность: кто отвечает за ревью, кто устанавливает исключения.
7. Процедура добавления нового инструмента в одобренный список.
8. Пересмотр и актуализация: раз в квартал или при появлении новых угроз.

8.2 Технические контроли

Без них документ — просто PDF.

• SAST в CI/CD как mandatory gate: блокирует merge при критических уязвимостях.
• Secret scanning как mandatory gate: блокирует merge при наличии секретов в диффе.
• SCA при добавлении зависимостей: проверка существования пакета, отсутствия open CVE.
• Автоматическое обнаружение AI-генерированного кода для приоритизации ревью.
• Мониторинг использования ИИ-инструментов: visibility без тотальной слежки — важно понимать, какие инструменты реально используются в команде.

8.3 Здесь и бывает разрыв

Типичная ситуация: политика написана, SAST настроен, SCA работает. Но команда не успевает дочитывать дифы — объём AI-генерированного кода вырос, а процесс ревью остался прежним. PR'ы мержатся быстро, а критические изменения — конфиги, зависимости, аутентификационный код — проходят через такой же ревью, как и очевидный boilerplate.

Здесь задача — не ещё один длинный security-отчёт, а короткий сигнал: «вот что в этом PR действительно требует твоего внимания прямо сейчас». Именно эту логику реализует HighVibe — слой контроля безопасности AI-кодинга, который анализирует конкретное изменение, объясняет риск простым языком и предлагает следующий шаг, а не добавляет ещё один скан в список задач HighVibe.

Часть 9. Типичные ошибки и как их избежать

Ошибка 1: Политика написана один раз и не обновляется.

Угрозы меняются быстро. Rules File Backdoor как вектор атаки появился в 2025 году, slopsquatting — в том же году. Политика без пересмотра устаревает за квартал. Обязательный пересмотр раз в квартал или при появлении новых значимых угроз.

Ошибка 2: Запрет без альтернативы.

«Не использовать внешние LLM» без указания, что можно, приводит к shadow AI. Политика должна давать разработчику понятный ответ: «что вместо этого».

Ошибка 3: Одинаковые требования для всего кода.

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

Ошибка 4: ИИ-агенты без идентификации и ограничений доступа.

Агентные сценарии (когда ИИ автономно создаёт PR, редактирует файлы, запускает тесты) требуют отдельного подхода: уникальный identity агента, scoped permissions, обязательный human approval для высокорисковых изменений [16]. Использование разработческих credentials агентом — потеря атрибутируемости.

Ошибка 5: Только документ без технических контролей.

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

Ошибка 6: Игнорирование транзитивных зависимостей.

85% разработчиков используют ИИ-ассистенты, но только 28% имеют хорошую видимость в слои транзитивных зависимостей, по данным Kusari [5]. Новая прямая зависимость проверяется, но то, что она тянет за собой — нет.

Часть 10. Decision framework: что делать прямо сейчас

Для команд, которые уже используют ИИ в разработке:

1. Провести инвентаризацию: какие инструменты реально используются в команде (включая личные аккаунты разработчиков). Без visibility нет управления.

1. Немедленно: настроить secret scanning как mandatory gate. Это самый быстрый win — блокирует наиболее очевидный риск.

1. Провести SCA-аудит зависимостей за последние 3–6 месяцев: сколько новых зависимостей добавлено, есть ли среди них пакеты с открытыми CVE или нехарактерно «молодые» пакеты без истории.

1. Проверить конфиг-файлы ИИ-инструментов в репозиториях (.cursorrules и аналоги): нет ли там инструкций, переопределяющих security-политики.

1. Принять «золотое правило»: разработчик, коммитящий код, несёт ответственность за него независимо от источника. Зафиксировать в policy.

1. Разработать классификацию компонентов по уровню риска: для high-risk компонентов ввести обязательный human review и запрет на AI-генерацию без явного согласования.

1. Обновить SDLC: добавить AI-специфические проверки на каждом этапе — в IDE (real-time SAST), в PR (mandatory gates), до релиза (финальный чеклист).

1. Пересматривать политику раз в квартал, отслеживая новые угрозы (OWASP LLM Top 10, CVE в используемых AI-инструментах, отчёты GitGuardian/Snyk/Endor Labs).

Заключение

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

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

Хорошая политика не создаёт бюрократию — она создаёт предсказуемость. Разработчик знает, что можно, что нельзя и что будет проверено автоматически. Security-команда получает видимость и контроль без необходимости читать каждый диф вручную.

Всё остальное — детали реализации, которые стоит настроить один раз и периодически пересматривать.

Источники

[1] Stack Overflow — "Stack Overflow Developer Survey 2025" — https://survey.stackoverflow.co/2025

[2] Hammond Pearce et al. — "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions" — https://arxiv.org/abs/2108.09293

[3] GitGuardian — "State of Secrets Sprawl 2026" — https://www.gitguardian.com/state-of-secrets-sprawl

[4] Fortune — "AI coding tools exploded in 2025. The first security exploits show what could go wrong" — https://fortune.com/2025/12/15/ai-coding-tools-security-exploit-software/

[5] Kusari — "AI Coding Assistants in 2026: 4× Faster, 10× Riskier. The Hidden Security Cost" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost

[6] IBM — "X-Force Threat Intelligence Index 2025" — https://www.ibm.com/reports/threat-intelligence

[7] arxiv.org — "Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories" — https://arxiv.org/html/2510.26103v1

[8] Quality Clouds — "Top AI Code Governance Tools Compared (Expert Guide)" — https://qualityclouds.ai/blog/ai-code-governance-tools-comparison

[9] Neil Perry et al. — "Do Users Write More Insecure Code with AI Assistants?" — https://arxiv.org/abs/2211.03622

[10] Witness.AI — "What Are AI Data Leaks? Causes, Risks, and Prevention" — https://witness.ai/blog/ai-data-leaks/

[11] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[12] OWASP — "OWASP Top 10 for LLM Applications 2025" — https://owasp.org/www-project-top-10-for-large-language-model-applications/

[13] Simon Roses Femerling — "The Dependency Trap: Supply Chain Risks in AI-Generated Code (Part 4)" — https://simonroses.com/2026/05/the-dependency-trap-supply-chain-risks-in-ai-generated-code-part-4/

[14] Pillar Security — "New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents" — https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents

[15] aidevdayindia.org — "Enterprise AI Coding Policy Template: How to Scale Securely in 2026" — https://aidevdayindia.org/blogs/best-ai-mode-checker/enterprise-ai-coding-policy-template-2026.html

[16] Knostic.AI — "AI Coding Agent Governance Policies That Work" — https://www.knostic.ai/blog/ai-coding-agent-governance

[17] OpenSSF — "Security-Focused Guide for AI Code Assistant Instructions" — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html

[18] Knostic.AI — "Governance for your AI Coding Assistant" — https://www.knostic.ai/blog/ai-coding-assistant-governance

[19] OWASP — "Secure Coding Practices – Quick Reference Guide" — https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/

[20] NIST — "SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models" — https://csrc.nist.gov/projects/ssdf

[21] Exceeds AI — "AI Governance Roadmap for Engineering Leaders in 2026" — https://blog.exceeds.ai/ai-governance-roadmap-engineering-2026/

[22] Habr — "Итоги 2025 в AI: прорывы, которые сдвинули индустрию, и ставки на 2026" — https://habr.com/ru/articles/979852/

[23] Coding Team / codingteam.ru — "Закон об ИИ в России 2025: что нужно бизнесу" — https://codingteam.ru/blog/zakon-ob-ii-v-rossii-i-mire-kak-regulirovanie-form

[24] FUTUREBY — "Искусственный Интеллект 2025: Новая Нормативная База для Бизнеса в России" — https://futureby.info/iskusstvennyj-intellekt-2025-novaya-normativnaya-baza-dlya-biznesa-v-rossii/

[25] Garant.ru — "Правовое регулирование искусственного интеллекта в России: Минцифры РФ разработало законопроект" — https://www.garant.ru/consult/popularnie-voprosi/2060216/

[26] CNews — "Российских разработчиков могут обязать раскрывать данные, на которых учился ИИ" — https://www.cnews.ru/news/top/2026-02-25_rossijah_razrabotchikov

[27] RBC — "В России обсудят запрет ИИ с «угрожающим уровнем риска»" — https://www.rbc.ru/technology_and_media/11/04/2025/67f7dc399a79477fdd97bf30