Нейросеть для написания кода в команде: где риски утечки и как их контролировать
ИИ в команде разработки — это как непредсказуемый цифровой стажер. С одной стороны, он может выполнить вашу задачу быстро и четко, делегируя на себя рутину и автоматизацию. С другой (если вы вдруг решите, что контроль за ним избыточен) — он может «подложить вам свинью» в виде уязвимого кода или утечки интеллектуальной собственности. И тут вне зависимости от результатов этой «русской рулетки» его выдачи ответственность и в том, и в этом случае, на вас.
Современное положение дел в ИТ-индустрии и в разработке имеет следующий парадокс в части использования при написании кода средств ИИ: по данным Т-Банка, 58% инженеров уже пишут код с помощью искусственного интеллекта, однако при всем при этом доверяют ему лишь 11% специалистов. На текущий момент бизнес массово внедряет новые технологии по типу LLM, а сами разработчики стали генерировать код значительно быстрее, 64% из них отмечают явный рост продуктивности. Однако при этом сам процесс разработки в целом так и не ускорился, а обусловлено это тем, что корпоративные процессы проверки кода, завязанные исключительно на человеке (код-ревью, вариативное тестирование, интеграция с другими системами и т. д.) банально не успевают за объемами и скоростями, которые задают машинной генерации.
Если говорить в общем, то сегодня 49% инженеров откровенно не доверяют нейросетям, относясь к ним именно как к сотруднику, за которым нужно постоянно перепроверять каждый шаг, в результате чего во многих задачах проще самому набросать, чем потом редактировать wipe-code. В данной статье мы разберем, чем обусловлена иллюзия скорости и автоматизация рутинности от ИИ, какие риски информационной безопасности в себе таят данные «плюшки», как публичные модели могут невзначай своровать корпоративную тайну и как с учетом всего этого выстроить процессы защищенной разработки и жесткую архитектуру контроля.
Почему строк кода больше, а релизы тормозят
На вопрос о том, ускоряет ли использование ИИ для написания кода релизы, нет однозначного ответа. Здесь все зависит от множества факторов, связанных как с использованием конкретной технологии, так и с процессами внутри компании, а сама эффективность напрямую зависит от выбранного сервиса, степени его так называемой «публичности» и глубины его работы с большими языковыми моделями.
Современные публичные ИИ сервисы можно классифицировать очень по-разному, например по уровню выдачи — от быстрого (поверхностного) ответа до профессионального и глубокого, адаптированного под конкретную отрасль (тот же wipe-coding).
- Если взять Gemini от Google, то несмотря на наличие у него заточенного под код Pro режима, модель все же демонстрирует наивысшую эффективность в качестве ИИ-помощника — некого интеллектуального собеседника, который отлично справляется с информационными задачами гуманитарной направленности.
- ChatGPT от OpenAI выдает прекрасные результаты в поиске информации и анализе массивов данных, однако для написания кода используется не часто. При этом сервис славится своей скованностью и огромным количеством этических ограничений.
- Изначально специализированный под код DeepSeek обладает направленностью именно на инженерную составляющую, и среди перечисленных систем он лучше всего пишет код, имея при этом встроенные ограничения для его безопасности (например, написать вредоносный скрипт для взлома он откажется).
Это все характеризует публичные сервисы в общем смысле, а при решении конкретных задач возникает в первую очередь проблема масштаба. Бесспорно, представленные ИИ-сервисы генерируют код весьма качественно, однако их успех применим в основном для идеальных «лабораторных» условий, будь то студенческий кейс «Hello world» или изолированный в отрыве от архитектуры ПО анализ данных или разработка «окна». Также использование сгенерированного кода в продакте критически усложняется тем, что стабильная работа enterprice-продукта требует идеальной взаимосвязи множества программных компонентов и модулей, причем написанных вдобавок различными разработчиками.
Именно на этапе интеграций сгенерированного кода нейросети чаще всего и дают сбой, и в итоге получается ситуация, когда разработчик, с одной стороны, экономит время на механическом наборе строк, а с другой тратит львиную долю ресурсов на правку этого кода и его внедрение в реальную, многогранную информационную систему заказчика. Отсюда скорость релизов падает, а разработка превращается в бесконечную адаптацию решения.
Как публичные LLM «воруют» коммерческую тайну
Помимо рассмотренного ранее падения качества, использование публичных нейросетей несет в себе угрозу, которую многие CISO и тимлиды недооценивают. И дело тут даже не столько в хакерах, парсящих своими сканерами открытые репозитории, и не в атаках MITM («человек посередине»), перехватывающих и затем расшифровывающих ваш запрос, защищенный через TLS. Главный риск заключается в телеметрии, открыто используемой публичными моделями, или, иначе говоря, в ситуации, когда ваш проприетарный код становится «топливом» для дообучения публичных платформ.
Механика так называемой «утечки» тут банального проста: когда разработчик вставляет кусок проприетарного кода в веб-интерфейс условного ChatGPT с безобидной просьбой «найди ошибку в архитектуре» или «оптимизируй алгоритм», то нейросеть выполнит задачу, но при этом паттерн, логика и сама интеллектуальная собственность осядут в телеметрии ИИ-сервиса. В результате уже завтра ваш прямой конкурент, попросив ИИ написать аналогичную функцию для своего B2B-продукта, сможет получить в выдаче фрагменты вашего закрытого кода, архитектура которого попадает под вашу коммерческую тайну и уникальность которого является прямой статьей дохода вашей компании.
Таким образом, при использовании публичных нейросетей для работы с корпоративным кодом коммерческая тайна и критическая информация сливаются в публичное окно чата добровольно руками самих сотрудников, а его телеметрия, циркулирующая в публичных моделях, представляет собой прямой риск компрометации вашего бизнеса.
Внедряем парадигму творческой отрасли киноиндустрии в структурированную индустрию ИТ
Для критических участков разработки кода, находящихся на уровне коммерческой тайны, использование публичных LLM должно стать абсолютным табу. Организовать это можно двумя подходами: радикальным и гибким. Поговорим подробнее про первый, когда в вопросах защиты интеллектуальной собственности в ИТ-сфере стоит перенять подход мирового кинематографа.
Когда монтируется еще не вышедший в прокат и ожидаемый всеми нами блокбастер или очередная серия нашумевшего сериала, доступ к его материалам ограничивается крайне параноидальными методами. Для работников киноиндустрии абсолютно обыденной практикой является подход, когда монтаж материалов происходит в изолированных контурах, без физического подключения к интернету и возможности стороннего захвата экрана. Делается это для того, чтобы исключить малейший риск слива и компрометации, а дополняет технический контур защиты юридическая сторона вопроса, при которой работник с таким уязвимым материалом в случае, если допустил его утечку, получает штраф на крупную сумму с множеством нулей и несет огромные репутационные риски для себя как надежного специалиста в сфере.
Аналогичный подход существует в разработке, называется он Air-gapped (воздушный зазор) и чаще всего используется в оборонной или «околостратегической» промышленности. В контексте рассматриваемой проблемы использование такого подхода означает необходимость развертывания локальных нейросетей на собственных серверах внутри изолированного контура компании, не имеющего доступа в интернет и обмен данными «с миром». Такой подход, безусловно, ресурсоемкий, требует закупки дорогих GPU и расходов на их сопровождение и содержание, отчего и внедряется преимущественно в оборонном секторе или Tier-1-банках. Однако такой радикальный подход, пожалуй, единственный способ гарантировать отсутствие утечек.
Техническую изоляцию важно закрепить юридической ответственностью. Одним из вариантов ее реализации является закрепление в договорах и NDA с разработчиками положений, что финансовые риски за компрометацию данных ложатся на сотрудника. Безусловно, это пугает, но в то же время достаточно эффективно отбивает желание переслать код через мессенджер или публичный репозиторий на домашний компьютер, чтобы «покодить на выходных». Такой подход крайне оправдан при защите от описанного риска, поскольку домашний ПК — это не только наличие дискретной видеокарты и доступа к удобному open-source-ПО для разработки, но и неконтролируемая, а оттого и крайне уязвимая среда, в которой сын разработчика мог скачать чит-код для Minecraft с зашитым в него троян-инфостилером, считывающим все файлы с диска и отправляющим их злоумышленникам.
Несмотря на эффективность такого подхода, доказанную опытом десятилетий существования киноиндустрии, он может оказаться «не по карману» или «не по удобству» весомому числу компаний, отчего стоит рассмотреть более гибкие подходы, позволяющие и нейросети для кодинга использовать, и при этом минимизировать его возможные утечки.
От корпоративных SLA до DLP-систем
Если бюджеты компании не позволяют развернуть радикальную, топорную, но надежную локальную инфраструктуру wipe-кодинга, то существуют промежуточные, более гибкие решения архитектуры контроля. Среди них стоит выделить следующие подходы:
- Корпоративные подписки на готовые Enterprise-решения с жестким SLA: сюда входит использование платных версий ИИ-сервисов, где вендор юридически и репутационно гарантирует соблюдение политики Zero Data Retention, заключающейся в полном отказе от использования ваших промптов и результатов их выдачи для обучения своих моделей. Однако выбор конкретной платформы — зона прямой ответственности руководителя разработки и службы ИБ.
- Интеграция DLP-систем с компонентами SAST. Современные системы предотвращения утечек уже умеют выявлять взаимодействие сотрудников с нейросетями и попытки передачи кода вовне. Если рассматривать настройку DLP в контексте рассматриваемой проблемы, то тут прежде всего необходимо сделать упор на мониторинг буфера обмена и активности в браузере, или, иными словами, — система должна детектировать и блокировать попытки отправки кусков программного кода, API-ключей или конфигурационных файлов в домены публичных чат-ботов.
Использование таких решений хоть и не даст абсолютную гарантию невозможности утечки кода через нейросети, однако существенно снизит риски и позволит в случае чего либо заранее предотвратить подобное действие через DLP-системы, либо «предъявить» юридическую ответственность за подобные действия вендору Enterprise-решения, нарушившему соблюдение Zero Data Retention согласно соглашению о конфиденциальности.
Требования к сгенерированному коду
В завершение хочется акцентировать внимание на том, что главное требование к сгенерированному коду заключается не в проценте его оригинальности и уровне заимствованном, аналогичном реферату по социологии, а в стабильности его работы и возможности enterprise-масштабирования в продакте. Иначе говоря, код должен быть не «красноречивым», а не падать при масштабировании и нагрузках, при этом отвечать принципам безопасной разработки, лаконичности, чтобы его могли читать и поддерживать другие разработчики. Если сгенерированный ИИ код идеально встает на свое место в продукте и соответствует этим критериям, он считается качественным, и не имеет значения, какой LLM он был написан.
Однако в то же время, именно здесь и кроется главный подвох написанного нейросетями кода, и заключается он в том, что ИИ не всегда способен выдать стабильный результат. К наиболее частым ошибкам машинной генерации относятся:
- Использование некорректных строк (таких как устаревшие версии языков или синтаксис других фреймворков);
- Нарушение программной логики (так называемый «грязный код» с «битыми» зависимостями);
- Критические уязвимости и бреши безопасности (например, отсутствие фильтрации «инъекций» от злоумышленников).
Несмотря на то, что ИИ способен избежать банальных «ошибок новичка» вроде переполнения буфера или зашитого внутри кода пароля, он в то же время зачастую не способен учесть всю сложность архитектуры вашего программного продукта и взаимосвязанных библиотек. Поэтому любой сгенерированный нейросетями код обязательно должен быть сведен к его жесткому тестированию.
Тут также важно понимать следующий постулат: есть задачи, которые принципиально нельзя доверять искусственному интеллекту, например из тех сфер, где за результат вы несете ответственность своим именем, репутацией или свободой (медицина, юриспруденция, военное дело и т. д.). Если провести аналогии, то врач не доверит ИИ постановку диагноза из-за риска для жизни пациента, а юрист не доверит вынесение обвинительного приговора (случаи использования ИИ помощниками судей уже имели большой резонанс и отменялись в вышестоящих инстанциях). Использовать нейросети для сбора статистики или поиска норм права допустимо, но доверять им финальный результат преступно.
Возвращаясь к нашей более гибкой сфере ИТ, то и тут мы приходим к best practice, при которой ни один адекватный эксперт не выпустит сгенерированный код в продакшн, не прогнав его «вдоль и поперек» тестами на совместимость и безопасность, поскольку в сухом остатке ИИ — это лишь мощный инструмент, аналогичный молотку в руках строителя. Он может сгенерировать что угодно, но ответственность за валидацию, внедрение, стабильность и возможные утечки всегда лежит на живом человеке и только на нем.
