Представим уже не экзотический сценарий. Разработчик поручает ИИ-агенту переделать авторизацию. Агент меняет несколько десятков файлов, тесты проходят, reviewer просматривает diff по диагонали, код уезжает в production. Через неделю выясняется, что один из обработчиков больше не проверяет принадлежность объекта пользователю. Клиенты могут читать чужие данные. На разборе инцидента звучит фраза «так написала модель».
С юридической и инженерной точки зрения такая фраза почти ничего не меняет. Российская Национальная стратегия развития искусственного интеллекта прямо закрепляет принцип, по которому ответственность за последствия работы системы ИИ нельзя переложить на саму систему. Но отсюда не следует и обратный вывод, будто за любой дефект автоматически отвечает программист, который нажал Enter. Ответственность зависит от договора, трудовых обязанностей, внутренних регламентов, характера ущерба и отраслевых требований. Поэтому корпоративный вайбкодинг я бы начинал не с выбора лучшей модели, а с ответа на четыре вопроса. Какой код модель вправе видеть, что ей разрешено менять, кто принимает результат и какие технические барьеры не дадут ошибке попасть в production.
Модель не виновник, но программиста тоже нельзя назначить крайним
В российском праве нет специального режима для «кода, написанного нейросетью». Если компания взяла перед клиентом обязательства по договору, исполняет требования к защите информации или выступает оператором персональных данных, применение ChatGPT, Claude, Copilot, Cursor или собственной модели само по себе не меняет сторону правоотношений.
При вреде, который сотрудник причинил при исполнении трудовых обязанностей, ГК РФ предусматривает ответственность работодателя в установленных законом случаях. Внутри компании ситуация другая. Работника можно привлечь к дисциплинарной ответственности за виновное нарушение трудовых обязанностей и локальных актов, а материальная ответственность регулируется Трудовым кодексом. По общему правилу речь идет о прямом действительном ущербе, а размер ответственности сотрудника ограничен средним месячным заработком, если закон не устанавливает оснований для полной материальной ответственности.
Поэтому пункт внутренней политики в духе «разработчик несет полную ответственность за любой код, созданный ИИ» выглядит эффектно только до первого спора. Нормальный регламент распределяет роли точнее.
| Роль | За что отвечает в процессе |
|---|---|
| Разработчик | За постановку задачи модели, просмотр результата, соблюдение ограничений по данным и передачу изменения на проверку |
| Reviewer | За предусмотренный процессом независимый просмотр изменений, особенно участков с правами доступа, данными и безопасностью |
| Владелец продукта | За принятие продуктового риска и критичность изменения |
| ИБ | За обязательные технические проверки, правила доступа агентов, контроль секретов и требования Secure SDLC |
| ИТ-платформа | За разрешенные инструменты, права агентов, CI/CD, журналирование и защищенные ветки |
| Юристы и специалисты по персональным данным | За допустимость передачи сведений провайдерам и договорные ограничения |
Такая схема нужна еще по одной причине. Формулировка «LLM сгенерировала уязвимость» обычно описывает непосредственное событие, но плохо описывает корневую причину инцидента. Если опасный код прошел без нормального review, статического анализа, проверки зависимостей и тестов разграничения доступа, проблема находится не только в ответе модели. Компания построила конвейер, в котором вероятностный генератор получил возможность провести дефект до production.
Хороший пример того, как быстро корпоративный эксперимент превращается в проблему управления данными, произошел в Samsung. Сотрудники передавали ChatGPT внутренние материалы, среди которых, по сообщениям СМИ, был исходный код, после чего компания ограничила применение публичных генеративных сервисов на корпоративных устройствах. Самый интересный вывод из такого случая не в том, что «ChatGPT опасен». Организация разрешила новый канал передачи информации раньше, чем успела определить правила работы с ним.
Что я бы написал во внутренней политике
Полный запрет генеративного ИИ кажется самым безопасным вариантом, но часто дает противоположный результат. Сотрудники продолжают пользоваться удобным инструментом через личные аккаунты, браузер и домашние устройства. Компания получает теневой ИИ, который практически невозможно контролировать. Я бы вводил белый список сервисов и одновременно делил инструменты не только по названиям, но и по возможностям.
Обычный чат видит текст, который сотрудник вставил вручную. IDE-ассистент способен читать соседние файлы. Агент может просматривать репозиторий, запускать команды, устанавливать пакеты, обращаться к сети и создавать commits. Подключение MCP, плагинов и внешних инструментов добавляет доступ к другим информационным системам. Два продукта с одной и той же моделью внутри могут создавать совершенно разный риск.
- Разрешить конкретные сервисы и режимы. В политике нужно перечислить корпоративные аккаунты, локальные модели, IDE-плагины и агентные среды. Фразы «разрешено использовать ИИ» недостаточно.
- Разделить информацию по классам. Публичный код и синтетические примеры имеют один уровень риска. Внутренние исходники, архитектура, клиентский код, персональные данные, ключи и материалы под NDA требуют другого режима.
- Запретить секреты в контексте модели. Токены, приватные ключи, пароли, production-конфигурации и реальные дампы баз не должны попадать во внешний сервис. Secret scanning полезно запускать не только перед commit, но и на данных, доступных агенту.
- Дать агенту минимальные права. Среда разработки не должна выдавать ИИ production-учетку, административный токен облака или возможность менять защищенную ветку только потому, что агенту так удобнее работать.
- Развести генерацию и приемку. Агент может подготовить ветку и pull request, но не должен сам одобрять собственный diff, обходить branch protection и выкатывать изменение в production.
- Сохранить обычный Secure SDLC. Сгенерированный код проходит тестирование, code review, SAST, SCA, поиск секретов и проверку используемых компонентов. Для критичного ПО добавляют динамический анализ, фаззинг и специализированные проверки.
- Выделить опасные участки. Авторизация, разграничение прав, криптография, платежи, обработка персональных данных, миграции БД, инфраструктурный код и CI/CD требуют более строгого ручного просмотра.
- Фиксировать происхождение изменения. Для значимых commits полезно хранить сведения о применении ИИ, инструменте, pull request, результатах проверок и человеке, который принял изменение. Полные prompts сохранять автоматически я бы не стал, поскольку журнал сам может превратиться в хранилище секретов и персональных данных.
- Предусмотреть отключение агента. Команда должна уметь быстро отозвать токены, закрыть сетевой доступ, остановить автоматические действия и сохранить журналы для расследования.
Отдельный проход второй моделью полезен, но я бы никогда не называл такую проверку независимым контролем. Модель-ревизор способна найти пропущенную проверку прав или подозрительный вызов API, однако две LLM могут одинаково принять неверное предположение из исходного задания. Зеленый ответ другого чат-бота не равен code review и не заменяет анализаторы.
Материал предназначен для законной и ответственной разработки и защиты собственных систем. Проверять уязвимости, код, учетные записи и инфраструктуру нужно только с разрешения владельца. При работе в России нужно учитывать законодательство о персональных данных, коммерческой тайне, критической информационной инфраструктуре и другой информации ограниченного доступа. Инструкции нельзя применять для несанкционированного доступа, слежки, взлома или нарушения правил сервисов.
Исходный код во внешнем ИИ-сервисе не просто «текст для модели»
Сам исходный код не относится автоматически к персональным данным или коммерческой тайне. Но реальный корпоративный репозиторий редко состоит только из безобидных функций. Рядом встречаются внутренние имена серверов, схемы API, комментарии разработчиков, тестовые учетные записи, конфигурация инфраструктуры, фрагменты клиентских данных, сертификаты и забытые токены.
Коммерческой тайной код тоже не становится только потому, что компания считает его секретным. Закон связывает соответствующий режим с конкретными мерами, включая определение перечня защищаемой информации, ограничение доступа, учет получивших доступ лиц, договорное регулирование отношений с работниками и контрагентами и маркировку документов. Отдельные обязательства по NDA и договорам с заказчиком могут действовать независимо от режима коммерческой тайны.
С персональными данными возникает еще один уровень проблемы. Если компания передает внешнему ИИ-провайдеру персональные данные для обработки, нужно оценивать законное основание, объем данных, цель обработки и отношения с получателем. Закон допускает поручение обработки другому лицу, но требует закрепить в таком поручении набор данных, операции, цели, конфиденциальность, требования к защите и уведомлению об инцидентах. Перед субъектом персональных данных ответственность во многих таких конструкциях продолжает нести оператор.
При зарубежной обработке может дополнительно возникнуть режим трансграничной передачи. Статья 12 закона № 152-ФЗ предусматривает отдельное уведомление Роскомнадзора и сбор сведений об иностранном получателе и мерах защиты. В июле 2026 года правила статьи снова изменились, в том числе критерии перечня стран с адекватной защитой и отдельные условия передачи. Поэтому старое заключение юриста, сделанное несколько лет назад для обычного облачного сервиса, я бы автоматически на ИИ-платформу не переносил.
Популярное обещание провайдера «мы не обучаем модели на ваших данных» решает только один вопрос. Для компании остаются хранение запросов, сроки удаления, резервные копии, доступ технической поддержки, местонахождение обработки, субподрядчики, телеметрия IDE, журналы, уведомление об инцидентах и возможность удалить переданные сведения.
Агентные среды делают картину еще неприятнее. Разработчик может честно сказать, что никогда не копировал файл с секретами в prompt. Агент при этом самостоятельно прочитал .env, конфигурацию Kubernetes или соседний файл с ключом и включил найденное значение в удаленный контекст. Поэтому политика должна контролировать не только содержание prompt, но и области файловой системы, которые видит агент, сетевой egress и набор доступных инструментов.
Локальная модель уменьшает риск передачи исходников стороннему облаку, но не отменяет остальные риски. Остаются происхождение весов, зависимости, плагины, контейнеры, обновления, телеметрия и права процесса. «On-premise» означает другую архитектуру доверия, а не автоматическую безопасность.
ФСТЭК и Банк России уже описывают знакомую картину
Главный российский стандарт здесь не про ИИ. ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» действует с 20 декабря 2024 года и заменил редакцию 2016 года. Стандарт описывает процесс безопасной разработки, включая управление требованиями, анализ угроз, правила безопасного программирования, анализ кода, динамические проверки, фаззинг, безопасную сборку, работу с секретами и композиционный анализ сторонних компонентов.
Национальные стандарты по общему правилу применяются добровольно, пока другой нормативный акт, договор или обязательная процедура не делает конкретные требования обязательными. Поэтому писать «весь российский бизнес обязан разрабатывать ПО по ГОСТ Р 56939-2024» неправильно.
Но для части организаций граница уже стала значительно жестче. Приказ ФСТЭК № 117 вступил в силу 1 марта 2026 года и распространяется на государственные информационные системы, а также охватываемые приказом системы государственных органов, государственных унитарных предприятий и государственных учреждений. Если оператор самостоятельно разрабатывает применяемое в таких системах программное обеспечение, приказ прямо требует реализовать меры разделов 4 и 5 ГОСТ Р 56939-2024. Порядок безопасной разработки также должен попасть во внутренние документы по защите информации. При привлечении подрядчика требования стандарта могут включить в техническое задание по решению руководителя или ответственного лица. Подробности требований собраны в разборе приказа № 117.
Для значимых объектов КИИ действует отдельный приказ ФСТЭК № 239. Документ содержит собственные требования к прикладному ПО, включая руководство по безопасной разработке, анализ угроз и испытания на уязвимости. Поэтому компании из регулируемых отраслей нельзя просто взять общий корпоративный шаблон «правил работы с ChatGPT». Сначала нужно определить, какие конкретно информационные системы и процессы подпадают под обязательные требования.
Самый свежий российский документ, который говорит об ИИ намного прямее, выпустил Банк России. В рекомендациях № 3-МР от 16 июня 2026 года регулятор описал меры информационной безопасности при разработке и применении ИИ на финансовом рынке. Это методические рекомендации, а не универсальный обязательный закон для каждой российской компании, но документ хорошо показывает направление регулирования.
Банк России предлагает включать безопасность ИИ во внутреннюю политику, распределять ответственность, проводить внутренний контроль и аудит, применять принцип минимальных привилегий, оценивать поставщиков и контролировать используемые компоненты. Для критичных автоматических операций при высоком риске рекомендуется проверка результата человеком с возможностью изменить решение системы.
Есть и несколько менее очевидных требований. При оценке поставщика предлагается смотреть на результаты аудитов, тестирования уязвимостей, практики безопасной разработки и даже программы Bug Bounty. Организациям рекомендуют вести перечень используемых открытых ИИ-компонентов, включая модели, агентов, плагины и интерфейсы API. Если внешний поставщик обучает модель на данных организации, Банк России предлагает передавать очищенные, обезличенные, синтетические или специально подготовленные наборы. В договоре с поставщиком рекомендуется закреплять ответственность за нарушения ИБ и обязанность сообщать об инцидентах и уязвимостях.
Мне такой подход кажется намного полезнее попытки придумать отдельное право для каждой строчки, написанной LLM. Вайбкодинг не отменяет Secure SDLC. Модель просто добавляет в жизненный цикл новый источник кода, новый канал передачи информации и нового субъекта доверия в виде поставщика ИИ.
Поэтому рабочий корпоративный регламент можно проверить пятью вопросами. Какие ИИ-инструменты имеют доступ к репозиторию. Какие данные разрешено передавать каждому из них. Какие права получает агент. Кто принимает критичный diff. Какие автоматические проверки способны остановить ошибочный релиз и какие доказательства останутся после инцидента.
Если на любой из этих вопросов компания отвечает «разработчик сам разберется», вайбкодинг уже внедрен, а управление риском еще нет. Самая разумная граница проходит не между «человеческим» и «нейросетевым» кодом. Граница проходит между изменением, которое прошло контролируемый процесс приемки, и изменением, которому поверили только потому, что модель написала его быстро и уверенно.
