Когда ИИ пишет код… Кто несёт ответственность?

Проблема, которую никто не хочет признавать

Фича выкатывается в пятницу. К понедельнику баг в биллинге успевает списать лишние деньги у 2 000 клиентов. Разработчик кивает на ИИ-ассистента. Вендор ИИ кивает на свой дисклеймер. Компания кивает на разработчика. А клиенты тем временем просто хотят вернуть свои деньги.

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

Почему это важнее, чем думает большинство команд

Правовое поле ужесточается

Суды и законодатели стремительно закрывают лазейки. Согласно анализу юридической ответственности за ИИ-код от BuildMVPFast, калифорнийский закон AB 316 (вступивший в силу 1 января 2026 года) прямо убивает защиту в духе «это сделал ИИ». Если компания разработала, модифицировала или развернула ИИ-систему, которая причинила вред, она не может заявить в суде, что ИИ действовал автономно. Под действие закона попадает вся цепочка поставок — разработчики, модификаторы, интеграторы, те, кто разворачивает систему.

Обновлённая Директива ЕС об ответственности за продукцию идёт ещё дальше. Производители остаются ответственными за самообучающиеся ИИ-системы, которые после развёртывания демонстрируют поведение, причиняющее вред, — даже за эмерджентное поведение, которое никогда не было явно запрограммировано. А прежний лимит ответственности (в Германии он составлял 85 миллионов евро) полностью отменён.

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

ИИ-вендоры уже провели свою границу

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

Здесь нет никакой двусмысленности. Вендоры чётко обозначили свою позицию: используете — значит, это ваша ответственность.

Трёхуровневая цепочка ответственности

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

Уровень 1: Компания

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

Уровень 2: Разработчик

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

Уровень 3: ИИ-вендор

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

Честная оценка: большинство споров сегодня ложатся на уровни 1 и 2. Рассчитывать на то, что ИИ-вендор выручит вашу команду, — нежизнеспособная стратегия.

Где именно ломается код, сгенерированный ИИ

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

Незаметный дрейф логики

Согласно анализу тестирования ИИ-кода от Testkube, ИИ-инструменты могут оптимизировать код способами, которые выглядят корректно, но нарушают неявные бизнес-правила. Их пример: ИИ рефакторит SQL-запрос, заменяя оператор != на конструкцию IN. Оптимизированный код работает быстрее и проходит интеграционные тесты, но исходный оператор определённым образом обрабатывал NULL-значения, от чего зависел ежемесячный финансовый отчёт. Баг всплывает через три недели, когда финансовый отдел формирует отчёты за месяц.

Это не падения. Это тихое повреждение данных — самый дорогостоящий вид багов.

Слепая зона тестирования

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

Накладные расходы на ревью съедают выигрыш в скорости

Обещание роста продуктивности от ИИ-инструментов для написания кода реально — пока дело не доходит до код-ревью. Согласно исследованию SoftwareSeni, инженерные команды сообщают, что ревью пулл-реквестов с большой долей ИИ-кода занимает на 26% больше времени, чем обычно. Ревьюеры сталкиваются с незнакомыми паттернами, более крупными PR и снижением уверенности при проверке кода, который они не писали.

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

Построение работающей системы ответственности

Классифицируйте код по уровню риска

Не весь код несёт одинаковые риски. Jellyfish рекомендует многоуровневый подход:

• Код высокого риска (аутентификация, платежи, персональные данные): ревью старшего разработчика плюс одобрение специалиста по безопасности
• Код среднего риска (бизнес-логика, API, обработка данных): тщательное peer-ревью с автоматизированным сканированием безопасности
• Код низкого риска (UI-компоненты, форматирование, документация): стандартный процесс ревью с базовым тестированием
• Экспериментальный код (прототипы, проверки концепции): на усмотрение разработчика, но участие ИИ должно быть задокументировано

Это не бюрократия ради бюрократии. Это соответствие инвестиций в ревью реальному риску — тот же принцип, по которому банки по-разному проверяют банковские переводы и снятие в банкомате.

Сделайте ИИ-код видимым

Testkube рекомендует помечать весь код, сгенерированный или написанный с помощью ИИ, в пулл-реквестах тегами вроде [AI-Generated] или [Copilot-Assisted]. Это переключает режим ревью. Ревьюеры переходят от «выглядит ли это правильно?» к активной проверке на отсутствие контекста, неявные бизнес-правила и несоответствия зависимостей.

Некоторые организации теперь требуют указывать процент участия ИИ в описании PR, запуская дополнительное ревью для PR с долей ИИ-контента более 30%.

Поднимите планку тестирования

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

Инструменты property-based тестирования (Hypothesis для Python, Fast-Check для JavaScript) особенно эффективны для выявления граничных ошибок, которые привносит ИИ. Они тестируют поведение, а не конкретные входные данные, что позволяет ловить баги категории «выглядит правильно, но таковым не является».

Проводите квартальные ИИ-аудиты

Продакшн-код, сгенерированный ИИ, должен пересматриваться каждые 3–6 месяцев. Ищите накопление технического долга, проблемы безопасности, которые прошли мимо первоначального ревью, и деградацию производительности. Это программный аналог инспекции здания — код выглядел нормально на момент выпуска, но как он себя ведёт в реальных условиях?

Разработайте чёткую ИИ-политику

Каждая ИИ-политика должна содержать следующие ключевые элементы, как описано у Jellyfish:

1. Процесс утверждения инструментов: какие ИИ-инструменты разрешены и кто утверждает новые
2. Правила владения кодом: кому принадлежит код, сгенерированный ИИ, и кто несёт ответственность в случае сбоя
3. Требования к документированию: что должно быть задокументировано — использованные промпты, задействованные инструменты, внесённые изменения
4. Стандарты ревью: дополнительные этапы проверки для ИИ-кода, особенно для компонентов, критичных с точки зрения безопасности
5. Обязательное обучение: разработчики должны пройти обучение по грамотной работе с ИИ, прежде чем использовать LLM в продакшне

Относитесь к ИИ как к джуниор-разработчику

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

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

Проблема атрофии навыков

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

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

Что это значит для регулируемых отраслей

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

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

Часто задаваемые вопросы

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

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

Если разработчик не может объяснить, как работает код, сгенерированный ИИ, должен ли такой код попадать в продакшн?

Нет. Код, который никто в команде не понимает, — это бремя для поддержки и кошмар для отладки. Инженерные руководители единодушно сообщают, что ускоренный с помощью ИИ выпуск создаёт серьёзные проблемы, когда что-то ломается и разработчик, закоммитивший код, не может объяснить его логику. Если вы не можете это объяснить, вы не сможете это поддерживать.

Как команды могут документировать участие человека в разработке с использованием ИИ для установления владения и ответственности?

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

Если ИИ рефакторит код и вносит незаметные баги по всей системе, кто несёт расходы на обнаружение и исправление этих каскадных последствий?

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