QEMU, один из ключевых проектов в мире виртуализации, может отказаться от полного запрета на вклад с использованием генеративного ИИ. Для тех, кто пишет, ревьюит или внедряет инфраструктурный open source, это сигнал простой: эпоха формулы «никакого ИИ вообще» заканчивается, а на смену ей приходит скучная, но взрослая модель управления риском. Именно поэтому дискуссия про QEMU и ИИ важна далеко за пределами одного репозитория.
Инициатором обсуждения стал Паоло Бонцини, distinguished engineer в Red Hat и мейнтейнер гипервизора KVM, сообщает The Register. 29 мая 2026 года он предложил смягчить действующую политику происхождения кода в QEMU: разрешать помощь ИИ там, где возможные последствия нарушений авторских прав легко откатить и где такой код вряд ли расползется по проекту. При этом ключевые части кодовой базы, по его идее, должны остаться закрытыми для ИИ-сгенерированных фрагментов без предварительного согласования с мейнтейнером.
Сейчас политика QEMU заметно жестче. Проект отклоняет все, что может включать в себя ИИ-сгенерированный контент или быть производным от него. Такой полный запрет был удобен, пока вывод LLM редко годился для прямого использования: правило простое, проверка тоже. Но аргумент Бонцини в том, что инструменты изменились. Когда модели стали чаще выдавать пригодные куски текста и кода, абсолютный бан перестал выглядеть безусловно рациональным. Проблема никуда не делась, но изменилась пропорция между риском и практической пользой.
Главный риск известен каждому, кто хоть раз спорил о лицензиях в open source: если разработчик приносит код, собранный с помощью ИИ, есть ли у него законное право этот код передать проекту? Вопрос не про качество автодополнения и не про скорость написания патча, а про происхождение результата. Если модель обучалась на фрагментах с разными лицензиями, а на выходе вдруг родился подозрительно знакомый кусок, мейнтейнеру придется разбираться уже не с красивой демкой, а с юридическим хвостом. Для инфраструктурных проектов это особенно неприятно: их код живет долго, встраивается глубоко и потом годами кочует по продуктам, дистрибутивам и корпоративным сборкам.
Именно поэтому Бонцини предлагает не открывать ворота настежь, а пускать ИИ в строго ограниченные зоны. В качестве примеров он называет небольшие багфиксы и документацию, то есть области, где спорный вклад можно быстро вырезать без цепной реакции по всей кодовой базе. Это довольно прагматичная логика. Небольшая правка в комментарии, описании параметра или локальном исправлении ошибки имеет иной профиль риска, чем изменения в core code, от которого зависят поведение виртуальных машин, совместимость и безопасность. Иными словами, если уж QEMU и ИИ начинают сосуществовать, то не на равных, а по пропускам и только в разрешенные комнаты.
Еще одна важная деталь обсуждения касается прозрачности. Один из возможных механизмов — явно отмечать, где именно использовался ИИ, с помощью специального трейлера вроде AI-used-for:. Это не просто бюрократия ради бюрократии. Для ревьюера такая пометка дает контекст: он понимает, на какие куски смотреть внимательнее, где могут быть лицензионные вопросы, а где ИИ ограничился тривиальной помощью вроде автодополнения имени переменной. В материале приводится и позиция Red Hat: там считают, что в некоторых случаях риск допустим, а раскрытие использования ИИ может и не требоваться, если помощь была совсем незначительной. Но у крупной компании есть юристы и ресурсы на разбор споров, а у самостоятельного open source-проекта такого комфорта обычно нет. Отсюда и более осторожная архитектура правил.
Контекст у этой истории шире самого QEMU. В open source уже не первый месяц спорят, что делать с кодом от ИИ-ассистентов: запрещать целиком, разрешать по умолчанию или строить промежуточные режимы. Полный запрет выглядит чисто и морально бодро, но плохо масштабируется, когда разработчики все равно пользуются подсказками в редакторе, генерацией тестов, черновиками документации и рефакторингом по запросу. Полное разрешение, наоборот, удобно в быту, но быстро упирается в вопросы о лицензиях, происхождении и ответственности. На этом фоне подход QEMU выглядит как попытка перевести спор из религиозного режима в инженерный: не «любим ли мы ИИ», а «где ущерб локализуем, кто несет ответственность и как это проверять».
Для русскоязычных команд здесь есть вполне прикладной вывод. Если ваш продукт зависит от open source-компонентов, особенно низкоуровневых, сама по себе фраза «код написал Copilot» или «текст сгенерировала модель» больше не годится ни как оправдание, ни как приговор. Нужна политика использования ИИ в разработке: где он допустим, что надо раскрывать в pull request, какие типы изменений требуют отдельного ревью и какие артефакты считаются слишком рискованными. Дискуссия вокруг QEMU и ИИ показывает, что следующая зрелая норма в индустрии — не запрет ради простоты и не вседозволенность ради скорости, а контроль происхождения кода с разной глубиной для разных частей системы. Самый интересный вопрос теперь не в том, снимет ли QEMU часть запрета, а в том, сколько еще инфраструктурных проектов тихо придут к той же схеме в ближайший год.