# Проверки происхождения кода ИИ перед внедрением

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

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

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

## Для четырех рисков нужны четыре отдельных решения

Авторское право, лицензии открытого ПО, коммерческие тайны и возмещение убытков пересекаются, но не заменяют друг друга. Сведите их в одну строку «юридический риск», и проверяющие одобрят успокаивающее заявление поставщика, которое решает лишь малую часть проблемы.

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

В отчете Бюро авторского права США «Авторское право и искусственный интеллект, часть 2» сказано, что при нынешних общедоступных технологиях одних промптов недостаточно, чтобы пользователь получил необходимый контроль и стал автором результата. Там же сказано, что человеческий отбор, компоновка или изменение могут получить защиту, если отвечают обычному критерию оригинальности. Для команд разработки это полезное предупреждение: фраза «наш сотрудник написал промпт» не заменяет анализ прав. Когда исключительные права имеют значение, сохраняйте проектные заметки человека и существенные правки, а трактовку местного права уточняйте у юриста.

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

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

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

## Сначала одобрите сервис, потом его код

Отдел закупок должен одобрять конкретный сервис, тариф, путь к модели и конфигурацию, а не название поставщика. Один поставщик может предлагать потребительский чат, корпоративного ассистента для программирования, API и локальную модель на разных условиях обработки данных. Формулировка «поставщик X одобрен» разрешает инженерам выбрать самый слабый путь.

Требуйте письменные ответы и ссылки на пункты договора по следующим темам:

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

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

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

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

Открытые веса требуют такой же проверки. Определение открытого ИИ от Open Source Initiative требует предоставить достаточно сведений о данных, чтобы специалист мог построить по существу эквивалентную систему, а также код обучения и выполнения и параметры модели на подходящих условиях. Файл весов, который можно скачать и который помечен разрешительной лицензией, может не соответствовать этому определению. Для внедрения еще важнее другое: лицензия модели, лицензия обучающего кода, условия весов, права на набор данных и условия использования сгенерированного результата могут различаться.

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

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

## Каждому принятому изменению нужна история источников

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

Для начала достаточно небольшой записи в репозитории:

```yaml
version: 1
change: payments/retry-policy
tool:
  service: approved-enterprise-assistant
  model: model-family-2026-05
  account: company-managed
inputs:
  repositories:
    - payments-api@8f2c19a
  prohibited_data: false
outputs:
  files:
    - src/retry.ts
  human_changes: substantial
checks:
  secret_scan: pass
  similarity_scan: pass
  dependency_scan: pass
  license_review: not_required
review:
  engineer: dev-184
  approver: lead-27
  date: 2026-07-18
```

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

Поле `prohibited_data` содержит подтверждение, а не волшебную защиту. Подкрепите его классификацией репозиториев, политикой рабочих устройств, управлением учетными записями и обучением сотрудников. Для поля `human_changes` тоже нужно командное определение. Я ставлю значение `substantial`, только когда инженер может объяснить решение, указать сгенерированные части и внес изменения серьезнее переименования или форматирования. Это операционное доказательство, а не юридический вывод об авторстве.

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

Обычные команды Git позволяют подтвердить, что изменение и запись сохранились вместе:

```bash
git show --name-only --format='commit=%H%nparent=%P%nauthor=%ae%nsubject=%s' HEAD
git show HEAD:.provenance/payments-retry-policy.yml
```

Форма вывода дает аудитору хеш коммита, родительский коммит, автора, тему, список измененных файлов и точную запись о происхождении из этого коммита. Если в записи указан `src/retry.ts`, а коммит меняет еще пять сгенерированных файлов, проверяющий его отклоняет. Такое простое сопоставление находит больше слабых одобрений, чем документ с политикой.

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

## Проверки сходства исследуют риск нарушения авторских прав

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

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

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

Сохраняйте ограничения детектора в записи об одобрении. Как минимум укажите охват корпуса, исключенные репозитории, поддерживаемые языки, минимальную длину совпадения и учет комментариев. Значок поставщика «фильтр публичного кода включен» не объясняет проверяющему, с чем в действительности сравнивали код.

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

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

Популярный совет запрещать любую подсказку, похожую на публичный код, звучит безопасно, но обычно не работает. В программах есть стандартные объявления, константы протоколов, сгенерированные привязки и типовые способы вызова API. Правило нулевых совпадений заваливает проверяющих шумом, приучает игнорировать предупреждения и может отклонять код, необходимый для совместимости. Исследуйте существенные совпадения и записывайте, почему каждое разрешили, переписали или удалили.

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

## Обязательства открытого ПО следуют за кодом

Открытый код сам по себе не означает сбой происхождения. Проблема возникает из-за скрытых или несовместимых обязательств. Политика одобрения должна позволять командам осознанно использовать компоненты и останавливать случайный импорт кода, условия которого никто не проверил.

SPDX дает компании точный словарь. `MIT`, `Apache-2.0` и `GPL-2.0-only` обозначают конкретные лицензии, а выражения вроде `Apache-2.0 OR MIT` описывают выбор. SPDX также проводит важное различие, которое команды упускают: короткие идентификаторы сообщают сведения о лицензии, а не о владельце авторских прав. Сохраняйте уведомления об авторских правах и не пытайтесь определить владельца по строке SPDX.

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

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

Проверяющий должен классифицировать каждую находку:

- зависимость с одобренной лицензией и зафиксированной версией
- скопированный или измененный исходник с сохраненными уведомлениями и выполненными обязательствами
- код с двойной лицензией и записанным выбранным вариантом
- конфликт лицензий, требующий замены или проверки юристом
- неизвестный источник или лицензия, которые блокируют слияние

Стандарт OpenChain ISO/IEC 5230 описывает соблюдение лицензий открытого ПО как программу с определенными процессами, ролями, ответственностью и постоянной работой. Я согласен с таким подходом. Разовая покупка сканера не решит, кто отвечает на вопрос об уведомлении, кто предоставляет исходники получателям и кто обновляет файл атрибуции после изменения зависимостей ИИ-ассистентом.

Сгенерированные тесты, примеры и конфигурации требуют той же проверки, если они поставляются с продуктом. Команды часто сканируют `src/`, но игнорируют скопированные тестовые данные или сгенерированные клиенты. Условия авторского права и лицензий не зависят от того, какой каталог разработчик считал важным.

## Коммерческие тайны требуют контроля входов и результатов

Самый быстрый способ подорвать доверие к внедрению ИИ - сказать инженерам «никогда не вставляйте секреты», одновременно дав ассистенту доступ к контексту всего репозитория. Секреты не ограничиваются паролями. Еще не выпущенные исходники, логика ценообразования, подробности инцидентов, клиентские записи, планы покупки компании, комментарии в закрытых задачах и код другой стороны по соглашению о неразглашении могут требовать ограниченного обращения.

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

Где возможно, обеспечьте соблюдение матрицы технически:

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

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

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

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

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

## Возмещение убытков должно работать при реальной претензии

Заголовок об освобождении от ответственности мало что дает, пока юрист не прочитает действующие условия. Полезно выяснить, кто получает защиту, какие претензии подпадают под нее, что обязан сделать поставщик, какие действия клиента отменяют защиту, кто управляет защитой и урегулированием и какие финансовые ограничения действуют.

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

Попросите юриста вынести в одобрение следующие поля:

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

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

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

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

## Уровни риска сохраняют соразмерность проверки

Одинаковая процедура для одноразового теста и платежного движка гарантированно породит обходные пути. Задавайте уровни по месту выполнения кода, его полномочиям, данным, способу распространения и сложности замены.

К низкому риску можно отнести выбрасываемые прототипы, внутренние скрипты без чувствительных данных и подсказки, которые инженер переписывает перед использованием. Требуйте одобренный сервис, обычную проверку кода, поиск секретов и короткую запись о происхождении.

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

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

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

Используйте контрольный список, который выдает решение, владельца и доказательства:

1. Убедитесь, что точный сервис, тариф, модель, учетная запись и конфигурация политики входят в список одобренных.
2. Классифицируйте каждый репозиторий и источник контекста, затем удалите запрещенные входные данные.
3. Укажите сгенерированные или существенно измененные ИИ файлы в записи о происхождении для запроса на слияние.
4. Выполните проверки безопасности, секретов, сходства, зависимостей и лицензий, обязательные для этого уровня риска.
5. Разберите совпадения и обязательства, сохранив источники, уведомления, решения и при необходимости заключение юриста.
6. Убедитесь, что условия покрытия убытков остаются включены, и приложите применимую версию договора.
7. Потребуйте, чтобы человек, который понимает код, одобрил его поведение, сопровождаемость и происхождение.
8. Сохраните запись вместе со слитым коммитом и повторно проверьте артефакт выпуска.

Этот список намеренно длиннее фразы «человек проверяет код». Проверяющий может найти состояние гонки и пропустить скопированный заголовок лицензии. Техническая правильность и происхождение требуют разных проверок.

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

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

## Сделайте политику проверяемой за один цикл выпуска

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

Распределите ответственность до покупки новых инструментов. Инженерная команда отвечает за правильное применение и запись в запросе на слияние. Безопасность отвечает за доступ к сервису, управление данными и инциденты. Сотрудники программы открытого ПО или назначенный инженер ведут лицензионные обязательства. Юристы толкуют права и договорное покрытие. Закупки хранят подписанные условия и уведомления об изменениях. В стартапе один человек может выполнять несколько ролей, но у обязанностей все равно должны быть имена.

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

Team & AI Audit от oleg.is может сопоставить этот процесс одобрения с затратами на разработку и ограничениями поставки, включая ситуации, где небольшой команде с ИИ нужны более сильные записи, а не новые совещания. Практический результат - контрольный путь, который существующая команда выполняет при каждом выпуске.

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