ИИ ускоряет разработку и накапливает долг управляемости
изображение: recraft
Почему скорость выпуска с ИИ создает долг управляемости, который потом оплачивают ИБ, эксплуатация и бизнес.
ИИ в разработке уже нельзя обсуждать как вопрос удобства команды. Это вопрос управляемого риска. Компания может выпускать код быстрее и одновременно повышать цену дефекта, отката и неверного изменения в промышленном контуре.
Я не спорю с DORA. Эти метрики нужны. Они показывают скорость прохождения изменений, частоту релизов, надежность и восстановление после сбоев. Но делать из них единственный язык разговора об автоматизации уже опасно.
ИИ может резко увеличить поток изменений там, где код, тесты, конфигурации и сценарии создаются быстрее, чем команда успевает их проверить. Быстрее появляются предложения на слияние кода, быстрее закрываются задачи, чаще происходит объединение веток. На графике это выглядит как рост производительности. Но график не показывает, сколько времени ушло на проверку кода, сколько изменений пришлось переписать, какой ущерб принес откат и где команда приняла риск, не успев его осознать.
Ускорение разработки с ИИ создает не только дополнительную производительность. Оно накапливает долг управляемости. Каждое изменение, которое команда не успела проверить, понять и обеспечить контролем, становится будущей стоимостью возврата, инцидента или простоя. Этот долг редко виден в момент релиза. Обычно он проявляется позже, когда система уже зависит от накопленных решений.
В этом и возникает ложная эффективность. Мы ускорили выпуск, но не посчитали стоимость возврата. Сократили время разработки, но увеличили нагрузку на проверку кода, тестирование, ИБ и эксплуатацию. Получили больше кода, но не обязательно больше результата.
Для крупной компании это уже не частный вопрос разработки. Изменение, созданное с участием ИИ, становится объектом управленческого учета. Его нельзя оценивать по моменту фиксации кода или даже по моменту релиза. Нужно считать полный цикл: подготовку, проверку, исправление, откат, влияние на SLA, стоимость простоя, трудозатраты на расследование и цену нарушения требований безопасности.
Именно здесь пересекаются интересы CISO, CIO, CTO и CFO. Для CTO это управляемость производственного процесса. Для CISO — контроль допуска, действий и последствий. Для CFO — реальная экономика автоматизации, а не отчет о сэкономленных часах.
Решение о масштабировании такой автоматизации нельзя принимать по числу сэкономленных часов. Нужна экономика полного цикла: стоимость внедрения и сопровождения, затраты на контроль, цена инцидента, ожидаемый эффект для срока вывода продукта и порог риска, который бизнес готов принять. Пока этого расчета нет, у компании не инвестиционный проект, а технический эксперимент.
К DORA я бы добавил два слоя показателей. Первый относится к качеству поставки: дефекты на тысячу строк кода, доля возвратов на доработку, время исправления инцидента, стоимость отката. Второй относится к безопасности: критические уязвимости до релиза, утечки секретов, нарушения политик доступа, изменения зависимостей, результаты проверок безопасности и доля рискованных изменений, прошедших обязательное подтверждение человека.
Без точки отсчета до внедрения эти показатели ничего не скажут. Нужно заранее зафиксировать исходное состояние, выбрать KPI, задать границы пилота и согласовать условия продолжения, корректировки курса или остановки проекта. В измерении автоматизации разработки уже используют именно такой связанный набор: предложения на слияние кода, дефекты на тысячу строк, качество проверки, время до объединения изменений и время до исправления, а не одну витринную метрику.
Контроль должен зависеть не от того, использовался ли ИИ, а от класса изменения. Черновик теста и типовой фрагмент кода — один уровень риска. Миграция базы данных, изменение прав доступа, инфраструктурный сценарий или компонент КИИ — другой. Для таких изменений нужны отдельные правила допуска, обязательная проверка человеком, неизменяемый журнал действий и право остановить выпуск до устранения риска.
Здесь и нужен доверенный контур. Разграничение доступа по ролям, журналирование, интеграция с SIEM, контроль опасных действий, а в закрытых средах — работа без внешней передачи данных. Это не набор технических опций. Это способ установить, кто инициировал изменение, кто его проверил, какие полномочия использовал и почему система пропустила его в релиз.
ИИ увеличивает цифровую инженерную мощность компании. Но без контроля эта мощность превращается в долг управляемости: в непрозрачные изменения, дорогие откаты и решения, за которые некому отвечать.
Зрелость компании теперь определяется не тем, как быстро она выпускает код с ИИ. А тем, какую долю этой новой мощности она умеет превратить в результат без потери контроля, безопасности и экономики.
Станислав Ежов, директор по развитию ИИ, ПАО «Группа Астра»
