Как внедрить ИИ в разработку компании без хаоса

Практическое руководство для CTO, VP Engineering и Tech Lead — от первого пилота до контроля качества в продакшне

Почему «просто попробуйте Copilot» не работает

Картина к началу 2026 года выглядит парадоксально. Инструменты AI-кодинга доступны всем: GitHub Copilot, Cursor, Claude Code, Amazon Q. Использование взлетело — по данным DORA 2025, 90% технических специалистов применяют ИИ в работе, тратя на него в среднем два часа в день [2]. По опросу McKinsey, 88% организаций регулярно используют генеративный ИИ хотя бы в одной функции [1]. В России, по данным «Яков и Партнёры», в 2025 году 71% компаний применяли генеративный ИИ хотя бы в одной из функций — рост на 17 п.п. за год [6].

И при этом — системный разрыв. McKinsey называет его "scaling gap": только около трети компаний перешли от экспериментов к реальному масштабированию. Только 6% получают ощутимый финансовый эффект [1]. BCG в своём исследовании CxO фиксирует схожее: 74% компаний не смогли извлечь ощутимой ценности из ИИ [7].

Причина не в технологии. Причина в том, как компании подходят к внедрению. Команды покупают инструменты, не выстраивая процессы. Развёртывают ИИ, не выстраивая governance. Ускоряют генерацию кода, не укрепляя контроль качества на стыке PR и релиза. Именно здесь и начинается хаос.

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

Часть 1. Что говорят данные: выгоды, риски и парадоксы

Ускорение есть, но оно неравномерно

Данные о производительности противоречивы — и это само по себе важный сигнал. McKinsey фиксирует, что в области software engineering и IT компании чаще всего сообщают о снижении затрат на 10–20% за счёт ИИ [1]. Среди ранних пилотов встречались заявления об ускорении кодогенерации на 30–50%, хотя типичный эффект для завершённых проектов составляет скромнее — 20–30% [8].

Однако DORA 2024 и 2025 добавляют важный нюанс: AI-ассистент повышает производительность конкретного разработчика, но эта производительность не всегда трансформируется в улучшение метрик всей команды. В 2024 году DORA обнаружил, что чем больше используется ИИ, тем хуже становятся показатели стабильности поставки [9]. В 2025 году картина немного улучшилась: появилась положительная корреляция с throughput, однако связь между AI-adoption и нестабильностью сохраняется [2].

Аналитика Faros AI по данным более 22 000 разработчиков в 2026 году зафиксировала явление, которое исследователи назвали «Acceleration Whiplash»: индивидуальная производительность растёт, количество завершённых задач увеличивается на 66%, но одновременно медианное время ревью PR выросло на 441%, а число инцидентов на один PR — в 2,4 раза [10].

Вывод исследователей DORA прямой: AI не исправляет слабую команду — он усиливает то, что уже есть. Сильные команды становятся ещё сильнее, у команд с плохими процессами проблемы усугубляются [2].

Три сигнала, которые нельзя игнорировать

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

Первый сигнал — качество и безопасность AI-кода. Совместное исследование CSA и Endor Labs показало, что 62% AI-генерированного кода содержит уязвимости или дефекты дизайна. По данным Veracode за 2025 год, 45% AI-кода уязвимо в соответствии с критериями OWASP Top 10 [4]. Независимое исследование обнаружило уязвимости примерно в 40% сниппетов, сгенерированных GitHub Copilot [11]. Природа уязвимостей предсказуема — SQL-инъекции (CWE-89), XSS (CWE-79), небезопасная десериализация — потому что модели обучались на публичном коде, который сам содержит эти паттерны [4].

Второй сигнал — hallucinated dependencies и slopsquatting. Исследование, опубликованное на USENIX Security Symposium (2025 г.), проанализировало 576 000 примеров кода на Python и JavaScript, сгенерированных 16 различными LLM. Почти 20% рекомендованных пакетов не существовали [3]. Коммерческие модели вроде GPT-4 галлюцинировали примерно в 5% случаев; открытые модели — примерно в 22%. При этом 43% галлюцинированных имён повторялись стабильно от запроса к запросу, что делает их предсказуемыми мишенями для атак: злоумышленники регистрируют пакеты с именами, которые ИИ постоянно рекомендует [3]. Этот вектор атак получил название slopsquatting — аналог typosquatting, но без опечаток.

Третий сигнал — масштаб уязвимостей растёт вместе со скоростью. По данным Apiiro, за первое полугодие 2025 года AI-генерированный код вносил более 10 000 новых security-находок в месяц по отслеживаемым репозиториям — рост в 10 раз за шесть месяцев. Число случаев эскалации привилегий выросло на 322%, архитектурные дефекты — на 153% [12]. Это классы проблем, которые не ловятся линтерами и труднее всего обнаруживаются при ревью.

Среди компаний, использующих GenAI, согласно одному из аналитических отчётов 2025 года, около 47% сталкивались с проблемами — от галлюцинаций до утечек данных [13].

Часть 2. Почему большинство пилотов не масштабируются

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

Пилот «без адреса»

Первая и самая распространённая ошибка — запуск пилота без чёткого ответа на вопрос «для чего конкретно». «Ускорить разработку» — не цель, это направление. Пилот без измеримой метрики успеха невозможно признать успешным или провальным, и он тихо умирает в статусе «используем, но не понятно, зачем» [7].

По данным BCG, компании, которые добиваются реального эффекта от ИИ, в первую очередь формулируют конкретную бизнес-задачу — снизить time-to-merge на X%, сократить долю багов в production на Y% — и под эту задачу выбирают инструмент [7].

Инструмент без политики

Исследования фиксируют устойчивый паттерн: сотрудники начинают использовать GenAI-инструменты до того, как компания выработала политику их использования. В 2024 году доля сотрудников, использующих GenAI на работе, выросла с 22% до 75% за один год [13]. Gartner прогнозирует, что более 40% AI-связанных утечек данных к 2027 году будут следствием несанкционированного или некорректного использования генеративного ИИ [13].

Среди ранних корпоративных пользователей GenAI 46% всех нарушений политики данных были связаны с тем, что разработчики вставляли проприетарный исходный код в инструменты GenAI для дебаггинга или генерации [13]. Разработчики стали одной из групп с наивысшим риском именно потому, что GenAI кратно ускоряет их работу, одновременно повышая вероятность нарушений.

Скорость без контроля

Главная ловушка AI-кодинга — функциональность не означает безопасность. PR может пройти все синтаксические проверки, тесты и выглядеть идеально при беглом взгляде — и при этом содержать архитектурный дефект, несуществующую зависимость или слишком широкий CORS. Чем быстрее работает команда, тем меньше времени остаётся на вдумчивое ревью каждого дифа [12].

По данным Faros AI, разработчики, использующие AI, взаимодействуют ежедневно на 67% с большим количеством контекстов PR и на 17,7% с большим количеством задач [10]. Когнитивная нагрузка растёт. PR дочитывают не до конца — особенно конфиги, служебные файлы, lock-файлы зависимостей и CI/CD-конфигурации.

Масштабирование без инфраструктуры

Ещё одна типичная ловушка — создание решения, которое хорошо работает при текущих объёмах и ломается при масштабировании. Архитектурные решения, рассчитанные на 1 000 запросов в день, дают сбой при 10 000 [14]. По данным исследования BCG, внутренние проекты по созданию AI-инструментов терпят неудачу вдвое чаще, чем проекты на основе партнёрства с вендорами [5]. В 95% компаний пилотные проекты по генеративному ИИ не дали эффекта согласно тому же анализу [5].

Часть 3. Дорожная карта внедрения: фазы и приоритеты

Ниже — структурированный подход, основанный на паттернах компаний, которые получили реальный эффект от AI-adoption. Он не является единственно верным, но отражает то, что стабильно отличает лидеров от застрявших на этапе эксперимента.

Фаза 0. Диагностика и baseline (2–4 недели)

Прежде чем выбирать инструмент, нужно понять, где сейчас находится команда. Что нужно зафиксировать как baseline:

1. Метрики поставки: lead time for changes, deployment frequency, change failure rate, MTTR (DORA-метрики).
2. Где тратится больше всего времени: кодогенерация, ревью, тестирование, документация, дебаггинг?
3. Текущее состояние практик: CI/CD-зрелость, code review coverage, автоматизация тестов, политика управления зависимостями.
4. Shadow AI: какие инструменты уже используются в командах без официального одобрения?

Без baseline невозможно доказать эффект пилота и невозможно обнаружить деградацию.

Также на этом этапе важно сформулировать 3–5 приоритетных сценариев для пилота — конкретных, с измеримыми KPI. Хорошие кандидаты: генерация тестов, автодокументация, ревью PR-описаний, помощь с boilerplate-кодом. Плохой кандидат на старте: полностью автономная генерация критических бизнес-компонентов.

Фаза 1. Governance до инструментов (параллельно с пилотом)

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

1. Политика использования ИИ-инструментов: какие инструменты одобрены, при каких условиях, какие данные нельзя передавать в сторонние сервисы. Это не опциональный документ: с февраля 2025 года требование об AI literacy для компаний, работающих в юрисдикции EU AI Act (Article 4), обязательно [15].
2. Политика данных: явный запрет на вставку проприетарного кода и чувствительных данных в публичные GenAI-сервисы.
3. Одобрённый список инструментов: централизованный реестр, через который проходит любой новый AI-инструмент перед использованием в командах.
4. Ответственный за AI governance — конкретный человек, а не «IT-отдел».

McKinsey выявил, что высокоэффективные компании в 2,8 раза чаще, чем остальные, проводят фундаментальный редизайн процессов в рамках AI-adoption [1]. Добавление AI поверх сломанного процесса только усиливает хаос.

Фаза 2. Пилот с контролем (6–10 недель)

Хороший пилот — это не «дали всем подписку и смотрим, что будет». Это структурированный эксперимент с гипотезой, метриками, временными рамками и критериями выхода.

Что важно на этапе пилота:

1. Выбрать небольшую команду (3–6 разработчиков), которая готова к эксперименту.
2. Сформулировать гипотезу: «использование AI-автодополнения сократит время на написание тестов на 30% при сохранении текущего coverage».
3. Измерять еженедельно: не только производительность, но и quality metrics — количество дефектов в PR, время ревью, изменения в составе зависимостей.
4. Проводить ретроспективы с командой: что работает, что создаёт трения.
5. Фиксировать паттерны генерируемого кода: какие уязвимости повторяются, какие зависимости появляются впервые.

На этом этапе особенно важно не распускать ревью. AI-ассистент создаёт иллюзию качества: код выглядит правдоподобно, компилируется, проходит базовые тесты. Именно это делает поверхностное ревью опасным. Команда должна явно договориться, что «работает» ≠ «готово к merge».

Фаза 3. Расширение с системным контролем

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

Первый: организационная поддержка. McKinsey фиксирует, что высокоэффективные компании в три раза чаще имеют активно вовлечённых в AI-adoption руководителей [1]. Трансформация не происходит снизу вверх без поддержки сверху. Нужны ресурсы на обучение, выделенное время на адаптацию рабочих процессов и явный сигнал от лидерства, что это приоритет.

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

Часть 4. Что и где проверять: контрольные точки

Самое уязвимое место при AI-кодинге — не отдельная строчка, а PR целиком в контексте релиза. Ниже — структура контроля, основанная на актуальных исследованиях.

До merge: что проверять в PR

1. Новые зависимости: существуют ли они в реестре (PyPI, npm, Maven)? Не являются ли они транзитивными рисками? Нет ли предупреждений в vulnerability advisories? ИИ-инструмент может порекомендовать пакет, которого не существует, или устаревшую версию с известной CVE [3].
2. Lock-файлы: обновлены ли они корректно? Совпадают ли версии с тем, что указано в манифесте?
3. Конфиги и служебные файлы: нет ли в CI/CD-конфигурациях, docker-compose, Kubernetes-манифестах изменений, расширяющих поверхность атаки? Не появились ли слишком широкий CORS, debug-режим или fallback-ключи?
4. Секреты: нет ли hardcoded credentials, токенов, ключей — в коде, в конфигах, в переменных среды, вложенных в коммит?
5. Архитектурные изменения: не удалены ли access control-проверки? Не заменена ли криптографическая библиотека на менее надёжную? Endor Labs называет такие незаметные изменения «архитектурным дрейфом» — они не нарушают синтаксис, но ломают security invariants [4].

Согласно данным CISO Guide by Checkmarx, ревью PR AI-генерированного кода требует особой дисциплины: традиционные SAST-инструменты часто не успевают за скоростью и объёмом изменений, а ручное ревью не масштабируется [11].

Перед релизом: что проверять в релизном контексте

1. Что именно входит в этот релиз? Какие новые зависимости появились за последние N PR?
2. Какие изменения в конфигурации затрагивают production?
3. Есть ли критические блокирующие находки, или это шум, который можно принять как технический долг?

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

SBOM и supply chain visibility

По мере роста использования ИИ возрастает значение Software Bill of Materials (SBOM). Если ИИ добавляет зависимости быстрее, чем команда их отслеживает, supply chain становится непрозрачной. SBOM — это не разовая задача, а непрерывный процесс, который должен быть частью CI/CD-пайплайна [4].

Часть 5. Типовые ошибки и как их избежать

Ошибка 1. «ИИ проверит сам себя»

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

Ошибка 2. Игнорирование shadow AI

Если у компании нет одобрённого списка инструментов, разработчики будут использовать то, что им удобно — включая личные аккаунты в публичных сервисах. Это создаёт риск утечки проприетарного кода. По данным одного из аналитических отчётов 2025 года, наиболее рискованные поведения сотрудников — загрузка чувствительных файлов и использование личных AI-приложений [13]. Правильный ответ — не запрет, а быстрое одобрение хороших инструментов и явная политика.

Ошибка 3. Метрики без контекста

Отслеживать только количество PR или скорость закрытия задач недостаточно. Нужна связка: скорость → качество → стабильность. Если PR-throughput растёт, а change failure rate тоже растёт — это не победа, это предупреждение [2].

Ошибка 4. Обучение «как пользоваться инструментом» без «зачем и как проверять»

По данным McKinsey, только около трети компаний в конце 2024 года называли change management и обучение приоритетом своих AI-внедрений [16]. Это означает, что большинство команд получают доступ к инструменту без понимания его ограничений. Разработчику нужно понимать: ИИ оптимизирует функциональность, а не безопасность; он не знает специфики вашего бизнес-контекста; у него нет памяти о предыдущих договорённостях команды, если вы не включили их в контекст.

Ошибка 5. «Вибкодинг» в production без gates

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

Часть 6. DORA AI Capabilities Model: что доказано работает

В 2025 году DORA выпустил новый компонент своей исследовательской программы — DORA AI Capabilities Model: набор из семи практик, которые показали статистически значимую корреляцию с позитивным влиянием AI-adoption на организационную производительность [2].

1. Чёткие рабочие процессы до внедрения ИИ. ИИ усиливает то, что есть. Если процесс размыт — ИИ делает его ещё менее предсказуемым.
2. Зрелые CI/CD-пайплайны. Команды с fast feedback loops получают выгоду от AI-ускорения; команды с медленными и нестабильными пайплайнами — нет.
3. Слабосвязанная (loosely coupled) архитектура. Монолиты с медленными циклами деплоя нивелируют преимущества AI-кодинга [2].
4. Культура user-centricity. Команды, фокусирующиеся на потребностях пользователя, показывают лучшие результаты от AI-adoption [2].
5. Автоматизированное тестирование. Без него рост скорости генерации кода неизбежно приводит к деградации качества.
6. Стабильные организационные приоритеты. Непоследовательность в приоритетах лидерства — один из самых сильных предикторов провала [9].
7. Psychological safety. Команды, в которых разработчики могут открыто говорить о сложностях и ошибках, быстрее учатся работать с ИИ-инструментами.

Часть 7. Decision framework: когда разрешать, когда блокировать

Не каждое AI-изменение требует одинакового уровня контроля. Вот практическая матрица принятия решений.

Можно принять с минимальным ревью:

1. AI-помощь с boilerplate-кодом, документацией, описаниями PR.
2. Генерация тестов для уже существующей логики.
3. Рефакторинг без изменения публичных интерфейсов.

Требует усиленного ревью:

1. Любые изменения в конфигурации (CI/CD, Docker, Kubernetes, CORS, auth).
2. Новые зависимости — даже хорошо известные.
3. Изменения в модулях аутентификации, авторизации, работы с данными пользователей.
4. Миграции базы данных.
5. Internal tools и служебный код.

Требует явного gate перед merge:

1. Галлюцинированные зависимости — блокирующий риск.
2. Hardcoded secrets — блокирующий риск.
3. Удаление или ослабление access control — блокирующий риск.
4. Критические CVE в добавленных пакетах — блокирующий риск.

Ключевой принцип: gate должен быть коротким и понятным. «Что блокирует выпуск прямо сейчас» — это другой вопрос, чем «что в кодовой базе потенциально может стать проблемой». Второй вопрос важен, но не должен стоять поперёк деплоя каждый раз.

Часть 8. Инструменты: как выбирать, что не упустить

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

При выборе AI-ассистента кодинга:

1. Уточнить: передаются ли данные на обучение модели? Можно ли отключить этот режим?
2. Проверить, какие данные и в каком объёме уходят на серверы вендора.
3. Убедиться в наличии enterprise-tier с явными SLA по безопасности данных.

При выборе инструментов контроля безопасности AI-кода:

1. Покрытие: анализирует ли инструмент конкретное изменение (диф) или требует полного сканирования репозитория?
2. Интеграция: встраивается ли в PR workflow, а не только в CI-конец пайплайна?
3. Сигнал vs. шум: выдаёт ли инструмент понятное действие («вот что нужно исправить») или длинный отчёт?
4. Покрытие зависимостей: отслеживает ли новые и транзитивные зависимости, проверяет ли их по advisories?

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

Часть 9. Российский контекст: специфика и дополнительные соображения

В России AI-adoption в разработке идёт по схожим паттернам, но с несколькими особенностями.

Первое: доступность иностранных инструментов. Многие команды перешли или рассматривают переход на отечественные или открытые альтернативы. По данным «Яков и Партнёры», 86% компаний, использующих генеративный ИИ, дообучают внешние open-source модели [6]. Это означает дополнительный слой ответственности: при fine-tuning критически важна чистота обучающих данных и контроль качества результата.

Второе: экосистема локальных LLM. В России доступны конкурентоспособные аналоги крупнейших LLM — YandexGPT (Alice AI) и GigaChat [6]. Для команд, работающих с чувствительными данными, это может быть важным соображением при выборе инструмента.

Третье: регуляторный контекст. Требования 152-ФЗ о персональных данных и отраслевые нормы (для финтеха, медицины, госсектора) добавляют ограничения на то, какие данные можно включать в контекст AI-инструментов. Это необходимо учитывать при формировании политики использования.

По данным ВШЭ, организации, использующие технологии ИИ, тратят на них около 15% общего объёма затрат на цифровые технологии [17]. Значительная часть этих затрат приходится на инфраструктуру. Это означает, что ROI-расчёт должен быть реалистичным: только около 6% компаний глобально видят возврат, превышающий 5% EBIT [1].

Часть 10. Тренды: куда движется AI-кодинг в 2025–2026

Несколько направлений, за которыми стоит следить.

AI-агенты в разработке. По данным McKinsey, компании-лидеры уже активно инвестируют в агентные системы: агенты могут планировать и исполнять многошаговые задачи — создавать PR, запускать тесты, обновлять зависимости. Это радикально меняет вопрос governance: агент с elevated privileges в production-среде — это новая поверхность атаки [1]. Один из российских трендов 2026 года по данным generation-ai.ru — активные инвестиции в агентные экосистемы [18].

Рост автономности и вопрос контроля. Cursor к апрелю 2025 года, по собственным данным компании, генерировал более миллиарда строк кода, вливаемых в репозитории ежедневно [4]. Контроль качества этого потока становится отдельной инженерной задачей.

Регуляторное давление. EU AI Act уже вступил в силу для ряда требований. Регуляторный ландшафт будет ужесточаться — для компаний, работающих с европейскими рынками, AI governance превращается из best practice в compliance requirement [15].

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

Заключение: что делать прямо сейчас

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

Три приоритета на ближайшие 90 дней для любой команды, которая всерьёз берётся за эту задачу:

1. Зафиксируйте baseline. Без текущих метрик невозможно измерить эффект — ни позитивный, ни деградацию.
2. Создайте governance до того, как он понадобится. Политика использования инструментов, список одобренных сервисов, понятные правила для разработчиков — это не тормоз, это условие для безопасного ускорения.
3. Встройте контроль на стыке PR и релиза. AI ускоряет генерацию, но не устраняет необходимость проверки. Чем выше скорость потока, тем важнее иметь чёткий и быстрый gate: что блокирует merge, что блокирует релиз.

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

Источники

[1] McKinsey — "The State of AI in 2025: Agents, Innovation, and Transformation" — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

[2] Google Cloud — "Announcing the 2025 DORA Report: State of AI-Assisted Software Development" — https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

[3] 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/

[4] 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

[5] UPR.ru — "Внедрение генеративного ИИ в бизнес 2025. Часть 1: «Разрыв генеративного ИИ» и результаты лидеров" — https://upr.ru/article/vnedrenie-generativnogo-ii-v-biznes-2025-chast-1/

[6] Яков и Партнёры — "Внедрение ИИ может принести российской экономике до 13 трлн руб. к 2030 г." — https://yakovpartners.ru/publications/ai-2025/

[7] Landau AI Hub — "Creating an AI Roadmap: From Vision to Implementation (12-month phased framework)" — https://landauai.com/resources/knowledge/ai-strategy/creating-an-ai-roadmap-from-vision-to-implementation/

[8] CheesecakeLabs — "AI for Software Development: Best Practices and Tools" — https://cheesecakelabs.com/blog/ai-for-software-development/

[9] DORA — "Accelerate State of DevOps Report 2024" — https://dora.dev/research/2024/dora-report/

[10] Faros AI — "DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics" — https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025

[11] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

[12] Apiiro — "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[13] MagicMirror Security — "The State of Enterprise AI in 2025: 17 Adoption, Risk, and Governance Insights" — https://www.magicmirror.team/blog/latest-adoption-risk-and-governance-insights-in-enterprise-ai

[14] Хабр / OTUS — "Почему большинство проектов в сфере ИИ терпят неудачу" — https://habr.com/ru/companies/otus/articles/977834/

[15] Landau AI Hub — "Creating an AI Roadmap: EU AI Act compliance notes" — https://landauai.com/resources/knowledge/ai-strategy/creating-an-ai-roadmap-from-vision-to-implementation/

[16] Stack AI — "The 7 Biggest AI Adoption Challenges for 2025" — https://www.stack-ai.com/blog/the-biggest-ai-adoption-challenges

[17] ИСИЭЗ НИУ ВШЭ — "Применение искусственного интеллекта в российских компаниях" — https://issek.hse.ru/news/1083541394.html

[18] Generation AI — "Тренды ИИ 2026 и итоги внедрения AI в российских компаниях за 2025" — https://generation-ai.ru/media/recap2025