QEMU går mot risikobasert AI-policy for kodebidrag

QEMU-prosjektet vurderer å myke opp forbudet mot AI-genererte kodebidrag. Forslaget er ikke et frislipp. Det er et skifte fra absolutt nei til risikobasert styring.

Paolo Bonzini, Red Hat-ingeniør og maintainer for KVM, har sendt et patchforslag til QEMU-devel-listen. I dag avviser QEMU bidrag som antas å inneholde eller være avledet fra AI-generert innhold. Bonzini skriver at et totalforbud var lett å forsvare da LLM-output sjelden kunne brukes alene, men at bedre verktøy gjør et absolutt forbud vanskeligere å begrunne.

Kjernen i forslaget er enkel. AI-assistanse kan tillates der en eventuell rettighets- eller lisensfeil er lett å reversere og lite sannsynlig å spre seg videre. Eksemplene er tester, dokumentasjon, mekaniske endringer og små feilrettinger. Kjernekode som andre deler av systemet bygger på, skal fortsatt være stengt uten forhåndsavtale med en maintainer.

The Register omtaler forslaget som et tegn på at store open source-prosjekter beveger seg bort fra blankoforbud. Det er presist. Den interessante nyheten er ikke at QEMU plutselig stoler på AI-kode. Den interessante nyheten er at prosjektet forsøker å lage en operativ modell for AI-bruk som både tar rettighetsrisiko og reviewer-belastning på alvor.

Rettigheter er ikke det eneste problemet

Bonzini peker på at Developer Certificate of Origin handler om hvorvidt bidragsyteren har juridisk rett til å sende inn koden. Den avklarer ikke alene statusen til output fra språkmodeller. Copyright- og lisensspørsmålene rundt LLM-generert kode er fortsatt uavklarte nok til at et community-prosjekt må være forsiktig.

Samtidig har risikobildet endret seg. Flere prosjekter og selskaper har tatt i bruk AI-assistanse uten store rettslige konflikter til nå. Red Hat har også vurdert risikoen som håndterbar i egen sammenheng. Men QEMU har ikke samme juridiske apparat som et stort selskap. Derfor legger forslaget vekten på områder der feil kan ryddes opp uten å rive med seg hele kodebasen.

Den andre risikoen er mer praktisk: vedlikeholderne drukner. AI senker kostnaden ved å produsere patcher. Den senker ikke automatisk kostnaden ved å forstå, teste og kvalitetssikre dem. Tvert imot kan review bli tyngre hvis reviewer ikke lenger kan anta at innsenderen har resonnerte gjennom hver linje.

Derfor foreslås også en egen trailer: «AI-used-for:». Den skal dokumentere hvor AI ble brukt i bidraget og gi reviewer et bedre utgangspunkt. Dette er ikke pynt. Det er audit-spor for kode.

Dette treffer bedrifter raskere enn de tror

Mange virksomheter har allerede utviklere som bruker Copilot, Claude Code, Codex eller interne kodeagenter. Likevel er policyen ofte binær eller uklar: enten «bruk AI smart» eller «ikke lim inn sensitiv kode». QEMU-forslaget viser en mer moden vei.

Første steg er sonedeling. Dokumentasjon, tester, migreringsskript og trivielle refaktoreringer kan ha én risikoklasse. Kjernebiblioteker, sikkerhetskritisk kode, infrastrukturkode og regulatorisk viktig logikk bør ha en annen. Samme modell kan ikke brukes overalt.

Andre steg er sporbarhet. Hvis AI har foreslått design, generert testdata, skrevet dokumentasjon eller produsert kode, bør det stå i commit, pull request eller intern endringslogg. Det gjør senere feilretting, lisensvurdering og incident review langt enklere.

Tredje steg er review-kapasitet. AI-verktøy kan øke volumet av endringer raskere enn organisasjonen klarer å kvalitetssikre dem. Det er en ledelsesrisiko, ikke bare en utviklerpreferanse. Flere pull requests er ikke verdiskaping hvis de flytter flaskehalsen til seniorutviklere, sikkerhetsteam og arkitekter.

Norske CIO-er bør kopiere prinsippet, ikke teksten

QEMU er spesielt fordi prosjektet ligger tett på virtualisering, maskinvareemulering og infrastruktur som mange andre systemer er avhengige av. Men prinsippet passer bredt. AI-assistert kode må vurderes etter hvor koden havner, hva den påvirker, hvor lett den kan reverseres, og hvem som må stå inne for den.

For CIO og CISO betyr det at AI-koding bør inn i endringsstyring, secure development, leverandørkrav og open source-policy. Ikke som et vedlegg. Som en del av vanlig software governance.

Det er fristende å se AI-kode som et produktivitetsverktøy for utviklere. QEMU-saken viser at den bedre beskrivelsen er kontrollert automatisering av software supply chain. Da må reglene være like konkrete som risikoen.

Kilder og medier

Primærkilde: QEMU-devel, Paolo Bonzini, «[PATCH] docs/devel: relax policy on AI-generated contributions», https://lists.nongnu.org/archive/html/qemu-devel/2026-05/msg07614.html

Top-tier verifisering: The Register, «QEMU mulls relaxing AI contribution ban», https://www.theregister.com/ai-ml/2026/05/29/qemu-mulls-relaxing-ai-contribution-ban/5248638

Thumbnail: OpenAI Image 2 / hogby.ai