Константин Попандопуло

Использование LLM в разработке стало массовой практикой: по данным Stack Overflow Developer Survey 2025, 84% разработчиков уже используют или планируют использовать ИИ-инструменты, а более половины делают это ежедневно. Код пишется быстрее, задачи закрываются быстрее, команды постепенно адаптируются к новой норме.

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

На практике ответ оказывается довольно прямым: за каждой ошибкой по-прежнему стоят конкретные имя и фамилия. Искусственный интеллект не становится самостоятельным участником процесса, не принимает решений и не несет рисков. Он лишь генерирует результат в рамках заданного контекста. А значит, ответственность никуда не исчезает — она просто смещается. Об этом рассуждает Константин Попандопуло, технический директор Umbrella IT.

Ошибка и проступок: где проходит граница

Чтобы корректно говорить об ответственности, важно различать два типа ситуаций:

  • ошибка возникает там, где не было четко заданных правил или контекста;

  • проступок — нарушение уже существующих требований и регламентов.

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

Отсюда и ключевой сдвиг: зона ответственности уходит от самого кода к качеству постановки задачи и полноте контекста.

Что на самом деле изменилось с распространением ИИ

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

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

В результате меняется не сама природа ошибки, а ее масштаб и стоимость устранения.

Почему вопрос ответственности стал критичным

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

  • Первая — рост стоимости ошибки. Объем изменений увеличился, а значит, сложнее стало находить источник проблемы. В ряде случаев дешевле пересобрать функциональность заново, чем разбираться в сгенерированном коде.

  • Вторая — переход от стабильных процессов к постоянным изменениям. Раньше команды работали в режиме run — с устоявшимися процессами и предсказуемой динамикой. Сегодня большинство компаний находятся в состоянии change: пересобирают команды, подходы и роли.

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

Где проходит реальная граница ответственности

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

Разработчик, в свою очередь, отвечает не за сам факт генерации, а за принятие решения. Модель предлагает вариант, но именно человек решает, использовать его или нет. Если код принят и попал в продакшн, ответственность остается на стороне команды.

Наиболее заметный сдвиг происходит на уровне бизнеса. Раньше задача могла быть сформулирована в общих чертах — опытный разработчик дополнял ее за счет своего понимания. Теперь эту роль частично берет на себя ИИ, который не интерпретирует задачу, а буквально следует заданному контексту. Если он неполный, результат может формально работать, но не соответствовать ожиданиям.

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

Из повозки — в авто, но есть нюанс

Хорошо объяснить происходящее поможет простая аналогия.

Раньше бизнес «ехал в повозке», где маршрут можно было задать крупными штрихами: опытная команда разработки уточняла детали, удерживала направление и помогала довести задачу до рабочего результата.

Теперь благодаря ИИ у бизнеса появилась возможность пересесть в дорогой новенький автомобиль. Скорость выросла, но и риски — тоже. Здесь уже нельзя полагаться на то, что команда точно поймет задачу как надо: водитель должен крепко держать управление. Если ослабить хватку, столкновение «со стеной» неизбежно.

Именно поэтому искусственный интеллект не стоит считать простым ускорением разработки. Это изменение роли бизнеса в процессе.

Где чаще всего «рвется» ответственность

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

  • Одна из самых распространенных ситуаций описывается фразой «ИИ предложил — человек закоммитил». Решение принято, но нигде не зафиксировано, кто его проверил и утвердил. В результате формально отвечает команда, но конкретная зона ответственности размывается.

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

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

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

Как меняется сама модель ответственности

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

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

Это требует другого подхода к управлению: ответственности нельзя «назначить постфактум», ее нужно заранее встроить в систему.

Что это означает для управления

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

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

Контекст как ключевой фактор качества

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

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

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

Что в итоге

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

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

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

Источник: