Все хотят помочь. В этом и проблема

Есть удобная картинка когда вайб-кодинг это про разработчиков. Пусть балуются, у них есть code review, CI, песочница, взрослые люди, знают как строить правильно.

Реальность в компании на 300 человек другая. Кодит и бэк офис и менеджмент.

Аккаунт собирает себе дашборд по проектам, строит пайплайны и системы для продаж, сервисы для контроля удовлетворенностью клиента. HR делает скрипт разбора резюме. Фин блок автоматизацию выгрузок и систему контроля рентабельности. Юристы про документооборот. Маркетинг - контент ферму. Никто из них не хочет сделать плохо. Наоборот: это лучшие сотрудники, те, кому не всё равно, кто решил не ждать полгода очереди в разработку и сделать сам. Мотивация идеальная, а вот последствия нет.

Как это выглядит со стороны инфраструктуры:

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

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

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

Дальше есть развилка, но оба случая для нас плохи.

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

Разрешить. Получаешь скорость и неконтролируемый периметр.

Мы выбрали третий вариант: не запрещать, а прокладывать дорожки.

Что это значит у нас на практике:

1️⃣ Регламент использования ИИ - что можно отправлять в модель, а что нет.
2️⃣ Реестр согласованных ИИ-инструментов - закрытый список того, чем можно пользоваться, с понятной процедурой пополнения.
3️⃣ Регламент выпуска ИИ-продуктов - как внутренняя поделка становится продуктом: владелец, ревью, обязательный security-чек.
4️⃣ За каждой виртуалкой закреплется владелец которые за нее отвечает.

Но регламент это просто текст. Сам по себе он не останавливает ничего. Поэтому под ним стоят два технических контура.

Первый это шлюз к моделям. Весь трафик к LLM идёт через него, не напрямую в провайдера. Работает inline, то есть не наблюдает постфактум, а стоит в разрыве: перед отправкой запрос проходит через слой обезличивания персданных, всё пишется в трейсинг, у каждого запроса есть автор. Побочный эффект оказался важнее основного: мы впервые увидели, что именно и куда люди отправляют.

Второй это конвейер проверок. SAST, DAST, SCA по зависимостям, SBOM с проверкой подписей и сертификатов, сканирование IaC. Всё, что идёт в релиз, проходит его независимо от того, кто и чем написал код: человек, модель или человек с моделью.

Оба контура контролируют штатные пути. Всё, что вне их, для них не существует. Шлюз ловит трафик к моделям. Конвейер ловит код, который дошёл до пайплайна. А система которую сотрудник захостил на виртуалке и запустил руками, не проходит ни через один из них. Технически он невидим. Его закрывают только инвентаризация, владелец у каждой машины и жёсткая процедура выдачи среды, то есть скучная административная работа.

Вывод, к которому мы пришли: работает только связка: правило + инструмент, который делает соблюдение правила самым простым путём. Если безопасный путь длиннее небезопасного, сотрудники выберут небезопасный, и в целом будут правы.