Кто отвечает за AI‑кодинг в команде: разработка, Tech Lead, DevOps или AppSec?

AI ускорил всех. Ответственность — нет

Зачем вообще разбирать, кто отвечает

Два года назад AI-ассистенты были в режиме эксперимента. Сегодня, по данным Black Duck за 2025 год, 85% организаций уже используют AI в разработке [4]. GitHub Copilot, Cursor, Claude Code, Amazon Q — инструменты стали обычным рабочим окружением, а не новинкой для пилотных проектов.

Скорость выросла. Объём PR вырос. А вот процессы контроля — нет.

Исследование CSO Online констатирует это прямо: традиционный DevSecOps предполагал, что код пишет человек. AI-авторство поставило новые вопросы — кто несёт ответственность за код, прошедший ревью, но позже вызвавший инцидент? Как отследить происхождение изменения? Как работать с тем, что разработчик вставляет в корпоративную кодовую базу фрагмент из consumer-инструмента вместе с лицензионным, security- или compliance-baggage? [5]

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

Что происходит, когда ответственность не определена

Прежде чем разбирать, кто за что отвечает, стоит посмотреть, что происходит при отсутствии этой ясности.

По данным исследования Aikido Dev, в котором участвовали 450 CISOов, разработчиков и AppSec-инженеров из Европы и США, каждый пятый опрошенный столкнулся с серьёзным инцидентом, связанным с AI-кодом [1]. При этом на вопрос, кто несёт ответственность за такой инцидент, 53% указали на команду безопасности, но ответы сильно расходились: часть — на разработчиков, часть — на продуктовых владельцев. Как отметил Энди Боура, CISO компании Rothesay, «среди респондентов нет чёткого понимания, где должна находиться ответственность за управление рисками» [1].

Это не философский вопрос. Это операционная дыра.

Когда ответственность неясна, происходит следующее:

Разработчик считает, что его задача — написать работающий код; безопасность — не его дело. Tech Lead думает, что «раз прошли тесты, значит, можно мержить». DevOps считает, что SAST в пайплайне покрывает риски — а команда безопасности видит только финальный артефакт, уже в production.

Результат предсказуем. По данным CodeRabbit, рост числа AI-ассистированных PR сопровождается ростом числа проблем: критические находки растут на 40%, серьёзные — на 70%, проблемы с логикой и корректностью — почти на 75% по сравнению с PR, написанными людьми [2]. При этом разработчики уделяют AI-коду меньше внимания при ревью — исследование Checkmarx показывает, что у них возникает ложное ощущение доверия к тому, что написал AI [6].

Итог: уязвимостей больше, внимания меньше, ответственность размыта.

Почему «сдвиг влево» — не ответ сам по себе

Концепция shift left — добавить безопасность как можно раньше в жизненный цикл разработки — остаётся правильной в своей широкой интерпретации. Но в узком смысле она провалилась.

Security Boulevard в марте 2026 года описывает два разных смысла этой концепции [3]:

Широкий shift left — это встраивание security-thinking ещё на этапе требований, дизайна, архитектурных решений. Это работает.

Узкий shift left — это сделать каждого разработчика ответственным за поиск и исправление уязвимостей в своём коде, снабдить его сканерами и ждать, что он это будет делать. Это не работает.

IBM подтверждает эту логику: добавление задач разработчику без снятия других нагрузок снижает продуктивность [7]. SC Media формулирует проблему точнее: когда сканеры дают много false positives, разработчики начинают их обходить или игнорировать — не из злого умысла, а потому что им нужно выпустить фичу в срок [8].

По данным Aikido Dev, 15% рабочего времени инженеров тратится на разбор алертов — это около $20 млн в год для команды из тысячи разработчиков [1]. При этом две трети опрошенных признались, что в той или иной форме обходят security-инструменты, откладывают исправления или игнорируют находки [1].

Это не признание некомпетентности. Это системная проблема: когда tools созданы только для безопасников, а не для разработчиков и безопасников одновременно, они создают трение, а не ценность. Aikido Dev показывает: команды, использующие инструменты, разработанные для обеих аудиторий, вдвое чаще сообщают об отсутствии инцидентов [1].

Вывод прост: ответственность нельзя просто делегировать вниз по иерархии. Нужна модель слоёв.

Модель слоёв: кто за что отвечает

Правильная модель распределения ответственности в AI-кодинге — это не передача задачи от одной роли к другой, а наслоение контроля на разных уровнях. Каждый слой закрывает свою зону риска.

Разработчик: первая линия, а не единственная

Разработчик — это тот, кто принимает AI-вывод и несёт за него ответственность перед командой. Ключевой принцип: AI-инструмент — это не автор, это соавтор. Любой код, принятый разработчиком, становится его кодом.

Это означает конкретные обязательства:

• Проверять AI-сгенерированный код так, как проверял бы код незнакомого junior-разработчика или неизвестного open-source пакета [9].
• Формулировать промпты с учётом security по умолчанию, а не в расчёте на исправление потом.
• Не мержить изменение, логику которого не можешь объяснить.
• Не копировать фрагменты из consumer AI-инструментов без проверки лицензий и зависимостей.

Addy Osmani формулирует это как жёсткое правило команды: как бы много ни внёс AI, человек обязан взять за это ответственность [10]. Это не метафора — это конкретная практика code ownership.

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

Tech Lead: стандарты и норма поведения в команде

Tech Lead определяет, как AI используется в команде, а не только что разрешено формально. В 2025 году это значит:

• Выработать и зафиксировать стандарты использования AI: какие инструменты одобрены, какие ограничены, что запрещено (например, вставка кода из consumer-инструментов без проверки).
• Установить правила ревью для AI-кода: не «посмотри» а «объясни, что делает каждый блок».
• Ввести явную политику для зависимостей: новая зависимость, предложенная AI, требует проверки отдельно от остального PR.
• Определить уровни доверия к AI-выводу в зависимости от чувствительности кода: auth, платёжные модули, миграции, конфиги CI/CD — выше порог проверки.

Согласно российскому исследованию «Состояние DevOps в России 2025» от Экспресс 42, добавить сканер в пайплайн недостаточно — 26,8% опрошенных признались, что результаты проверок им непонятны [11]. Tech Lead — это тот, кто делает результаты понятными и встраивает понимание в культуру команды.

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

DevOps / Platform Engineering: gate и пайплайн

DevOps и команда platform engineering отвечают за то, чтобы никакой код — человеческий или AI-сгенерированный — не попал в production без прохождения автоматических проверок. Это механический уровень контроля, который не зависит от сознательности отдельного разработчика.

Конкретные зоны ответственности:

• SAST, SCA, secret detection запущены на каждый PR — не выборочно, не вручную [12].
• Политика блокировки merge при нахождении критических уязвимостей настроена и не отключается без эскалации.
• Новые зависимости, появившиеся в PR (включая транзитивные), подсвечиваются отдельно и проверяются на known advisories.
• Lock-файлы включены в ревью как first-class граждане.
• Конфигурационные файлы (CI/CD, IAC, docker, .env) проходят отдельную проверку — AI особенно склонен генерировать небезопасные дефолты в конфигах [9].

По данным DZone за 2026 год, команды, которые прошли через волну экспериментов с AI в 2024–2025, сейчас сталкиваются с «integration tax»: десятки кастомных скриптов, несогласованные стандарты, непрозрачное владение [13]. Platform engineering — это не просто автоматизация, это стандартизация, без которой AI-ускорение превращается в технический долг.

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

AppSec: политики, сигналы и релизный gate

AppSec — это не финальный контролёр, который смотрит на артефакт перед деплоем. В модели со слоями AppSec отвечает за:

• Определение политик: что считается критическим для блокировки, что — для уведомления, что — для отслеживания.
• Настройку инструментов: SAST, SCA, SBOM — правила должны быть настроены под специфику продукта, а не взяты out-of-the-box.
• Threat modeling для новых AI-фич: если продукт использует LLM в пользовательском интерфейсе, AppSec должен проработать сценарии prompt injection — это отдельная поверхность атаки [14].
• Релизный gate: перед выпуском AppSec должен дать ответ на конкретный вопрос — есть ли в этом релизе что-то, что блокирует выпуск. Не длинный отчёт, а конкретный ответ.
• Работу с supply chain: AI-инструменты могут предлагать пакеты с похожими именами, но являющимися либо вредоносными, либо несуществующими (package hallucinations) [9].

Исследование Aikido Dev показывает: команды, использующие раздельные инструменты для AppSec и Cloud Security, на 50% чаще сталкиваются с инцидентами, чем те, кто объединил эти программы [1]. AppSec должен работать не как отдельный бункер, а как часть единого потока.

Где чаще всего застревает ответственность

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

Конфиги и CI/CD-файлы. Их читают хуже всего. AI генерирует .github/workflows, docker-compose.yml, terraform, .env-шаблоны — и в них регулярно оказываются небезопасные дефолты, широкие permissions, закомментированные секреты. Ни разработчик, ни Tech Lead не считают конфиги «своим» кодом. DevOps смотрит на них с точки зрения работоспособности, а не безопасности.

Зависимости. AI предлагает зависимости с той же скоростью, с которой пишет код. Новый пакет может оказаться устаревшим, уязвимым или несуществующим (hallucination). Транзитивные зависимости вообще не видны при ревью. Это зона, где SAST недостаточно — нужен SCA с актуальной базой advisories.

Служебный и internal-код. Скрипты автоматизации, миграции баз данных, internal dashboards — их ревьюят по остаточному принципу. AI пишет их быстро, они попадают в репозиторий без должного внимания, а потом живут годами. Это именно тот код, в котором чаще всего находят хардкоднутые секреты, чрезмерные привилегии и fallback-ключи.

Момент перед релизом. Ещё один длинный security-отчёт за день до деплоя — не помогает принять решение. Команда не знает, что из найденного критично прямо сейчас, а что можно отложить. Отсутствие чёткого «стоп / можно» приводит либо к заморозке релиза без причины, либо к выпуску с известными рисками.

RACI для AI-кодинга: практическая схема

Рабочая модель распределения ответственности для AI-кодинга строится по принципу RACI — кто Responsible (исполняет), Accountable (отвечает за результат), Consulted (участвует в обсуждении), Informed (получает информацию) [15].

Принятие AI-вывода в PR: Responsible — разработчик, Accountable — разработчик + Tech Lead.

Стандарты использования AI-инструментов: Responsible — Tech Lead, Accountable — Tech Lead, Consulted — AppSec.

Политики проверок в CI/CD: Responsible — DevOps/Platform, Accountable — Tech Lead, Consulted — AppSec.

Проверка новых зависимостей: Responsible — DevOps/Platform + разработчик, Accountable — Tech Lead, Consulted — AppSec.

Threat modeling для AI-фич: Responsible — AppSec, Accountable — AppSec + Tech Lead, Consulted — разработчик.

Релизный gate (финальное одобрение): Responsible — AppSec, Accountable — Tech Lead / Engineering Manager.

Инцидент после релиза: Accountable — Engineering Manager + Tech Lead; Responsible — тот, кто принял конкретный PR.

Ключевой принцип, который проходит через все эти строки: ответственность должна следовать за решением. Если Tech Lead устанавливает правила — он отвечает за то, что они выполняются. Если разработчик принял AI-вывод без проверки — это его ответственность, а не AI-инструмента.

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

Ошибка 1: AppSec включается только в конце.

Симптом: AppSec-команда видит код впервые на этапе code freeze или перед production. Находит критические проблемы — деплой срывается, все злятся.

Как исправить: AppSec должен участвовать на этапе определения требований к AI-фичам и задавать правила для пайплайна до начала разработки. Это широкий shift left в правильном смысле слова [3].

Ошибка 2: Сканеры есть, но их результаты никто не читает.

Симптом: SAST запущен, отчёты генерируются, но разработчики привыкли их игнорировать из-за шума. DevOps знает об этом, но не эскалирует.

Как исправить: настроить инструменты на минимальный шум и максимальную точность. Для AI-кода особенно важно — false positive rate должен быть низким, иначе люди перестают доверять сигналу [1]. Разделить алерты по приоритету: что блокирует merge, что требует внимания, что фиксируется для backlog.

Ошибка 3: Новые зависимости от AI не проходят отдельную проверку.

Симптом: в PR появляется новый пакет, предложенный Copilot. Разработчик проверяет, что он работает. Никто не проверяет, есть ли у него CVE, откуда он, каковы его транзитивные зависимости.

Как исправить: SCA должен быть включён в пайплайн с явным выделением новых зависимостей. Tech Lead должен требовать отдельного обоснования для каждой новой зависимости в AI-сгенерированном коде [9].

Ошибка 4: AI-инструменты используются без политики.

Симптом: одни разработчики используют GitHub Copilot, другие — Cursor с Claude, третьи — ChatGPT напрямую. Никто не знает, какой код откуда пришёл и несёт ли он лицензионные или security-риски.

Как исправить: Tech Lead вместе с AppSec формирует явный список одобренных инструментов. Это не запрет, а управление, аналогичное тому, как CISOы десять лет назад перестали запрещать Dropbox и начали управлять им [6]. Согласно российскому исследованию DevOps 2025, по-прежнему популярна гибридная модель — важно хотя бы зафиксировать, какие инструменты в ней используются [11].

Ошибка 5: Конфиги и serve-файлы выпадают из ревью.

Симптом: разработчик или AI генерирует CI/CD-конфиг, Dockerfile, IaC-манифест — и это идёт в PR как «не совсем код», поэтому его смотрят поверхностно.

Как исправить: конфигурационные файлы должны проходить ту же цепочку проверок, что и application code. DevOps настраивает отдельные правила для конфигов; Tech Lead фиксирует это как стандарт ревью.

Будущее модели: куда движется распределение ответственности

Тренд 2025–2026 — это переход от «shift left» к «shift everywhere»: проверки на каждом уровне, встроенные в workflow, а не вынесенные за его пределы [7].

Несколько направлений, которые меняют модель прямо сейчас:

Agentic AI. Следующий шаг после AI-ассистентов — агенты, которые сами открывают PR, создают зависимости, изменяют конфиги. OWASP уже выпустил отдельный список угроз для agentic AI-систем [14]. Когда агент действует автономно, вопрос «кто принял это решение» становится ещё острее. Ответственность за действия агента должна быть заранее назначена человеку — иначе она никому не принадлежит.

Platform engineering как несущая конструкция. Исследование DZone за 2026 год описывает это как основной приоритет после хаоса 2024–2025 [13]. Внутренние платформы с встроенными guardrails, policy-as-code и стандартизированными пайплайнами позволяют масштабировать AI-кодинг без потери контроля.

SBOM как новый стандарт. CISA уже требует минимальный набор элементов для Software Bill of Materials [13]. Для AI-кода это означает, что происхождение каждого компонента — включая те, что предложил AI-ассистент — должно быть отслеживаемым.

96% опрошенных в исследовании Aikido Dev считают, что AI будет писать безопасный и надёжный код — но только 21% думает, что это произойдёт без человеческого контроля [1]. Это и есть формула: ускорение без надзора — это не ускорение, это риск.

Практический чек-лист для команды

Перед merge:

• Разработчик может объяснить логику каждого блока AI-кода
• Новые зависимости проверены отдельно (SCA, advisories)
• Конфиги и CI/CD-файлы прошли ревью
• Нет хардкоднутых секретов, токенов, fallback-ключей
• SAST прошёл без критических находок (или критические исключения согласованы)

Перед релизом:

• AppSec дал ответ: есть ли находки, блокирующие выпуск
• Новые внешние зависимости перечислены и обоснованы
• Изменения в конфигах задокументированы
• Если в релизе есть AI-фичи с пользовательским вводом — проверены сценарии prompt injection

На уровне процессов:

• Список одобренных AI-инструментов существует и актуален
• Tech Lead определил правила ревью для AI-кода
• AppSec включён в обсуждение требований для AI-фич
• Результаты пайплайна понятны команде, а не только security-специалистам

Слой, которого часто не хватает

Даже при правильно выстроенных зонах ответственности остаётся один практический пробел: между автоматическими проверками в CI/CD и финальным решением «мержить или нет» нет понятного интерпретатора.

SAST дал 40 находок. Какие из них реально блокируют релиз? DevOps видит отчёт, но не имеет контекста продукта. AppSec не смотрит каждый PR. Разработчик видит findings, но не знает приоритет. Tech Lead хочет понять риск, но не хочет читать длинный отчёт.

Именно для этого случая существуют решения, работающие как дополнительный слой контроля до merge — не заменяющие SAST/SCA/CI-проверки, а помогающие команде понять, что конкретно в этом PR и конкретно в этом контексте релиза является реальным стопом. HighVibe работает именно так: анализирует конкретное изменение и релизный контекст, объясняет проблему простым языком и предлагает следующий шаг — исправить, перепроверить или остановить merge подробнее на HighVibe.

Это не про тотальное сканирование и не про длинный отчёт. Это про короткий и понятный сигнал в нужный момент.

Заключение: ответственность как архитектурное решение

В инженерии мы хорошо понимаем идею Single Responsibility Principle — каждый компонент делает одно и делает хорошо. В команде с AI-кодингом та же логика: каждая роль закрывает свой слой, а не пытается покрыть всё сразу.

• Разработчик — принимает AI-вывод и несёт ответственность за него.
• Tech Lead — устанавливает стандарты и норму поведения.
• DevOps/Platform — обеспечивает автоматические gate в пайплайне.
• AppSec — определяет политики, читает сигналы, даёт ответ на вопрос «можно ли выпускать».

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

Если хотя бы один слой пропущен или его ответственность не зафиксирована — жди инцидента. Вопрос только в том, когда и насколько дорогого.

Источники

[1] Aikido Dev — "State of AI in Security & Development 2026" — https://www.aikido.dev/state-of-ai-security-development-2026

[2] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[3] Security Boulevard — "Shift Left Has Shifted Wrong: Why AppSec Teams — Not Developers — Must Lead Security in the Age of AI Coding" — https://securityboulevard.com/2026/03/shift-left-has-shifted-wrong-why-appsec-teams-not-developers-must-lead-security-in-the-age-of-ai-coding/

[4] Black Duck — "AI Coding Assistant Risks and Benefits: 2025 DevSecOps Security Guide" — https://www.blackduck.com/blog/ai-coding-assistant-security-risks-benefits-devsecops-2025.html

[5] CSO Online — "AI is reshaping DevSecOps to bring security closer to the code" — https://www.csoonline.com/article/4163355/ai-is-reshaping-devsecops-to-bring-security-closer-to-the-code.html

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

[7] IBM — "Beyond Shift Left: How 'Shifting Everywhere' With AI Agents Can Improve DevOps Processes" — https://www.ibm.com/think/insights/ai-in-devops

[8] SC Media — "AI code is creating security bottlenecks faster than it's solving them" — https://www.scworld.com/perspective/ai-code-is-creating-security-bottlenecks-faster-than-its-solving-them

[9] Apiiro — "AI-Generated Code Security: Security Risks and Opportunities" — https://apiiro.com/blog/ai-generated-code-security/

[10] Addy Osmani / Elevate — "Code Review in the Age of AI" — https://addyo.substack.com/p/code-review-in-the-age-of-ai

[11] Новости IT Канала — "State of DevOps Russia 2025: рост зрелости команд, интеграция AI и приоритет безопасности" — https://www.novostiitkanala.ru/news/detail.php?ID=191902

[12] GitLab — "Shift Left Security: A Complete Guide" — https://about.gitlab.com/topics/devsecops/shift-left-security/

[13] DZone — "6 Software Development and DevOps Trends Shaping 2026" — https://dzone.com/articles/software-devops-trends-shaping-2026

[14] OWASP GenAI Security Project — "OWASP Top 10 for LLM Applications 2025" — https://genai.owasp.org/

[15] Yields.io — "RACI Matrix: Defining Accountability in AI Governance" — https://www.yields.io/blog/raci-matrix-ai-governance/