Per anni, la comunità del kernel Linux ha chiesto che le patch sviluppate con il contributo di strumenti di AI/LLM fossero accompagnate da un tag "Assisted-by". L'obiettivo era rendere esplicita l'origine parzialmente artificiale del codice, in modo che manutentori e revisori potessero valutarne la qualità con più contesto. Oggi gli sviluppatori stanno valutando di eliminare questo requisito, con la motivazione che l'uso ormai pervasivo dei LLM rende il tag poco pratico.

La proposta non è solo una semplificazione formale. Riflette un cambiamento strutturale nel modo in cui il software viene prodotto: se l'assistenza di un LLM è diventata la norma, distinguere il contributo umano da quello sintetico perde valore informativo. In un flusso di sviluppo in cui i modelli generativi sono integrati negli editor, nei completamenti automatici e nelle pipeline di revisione, un singolo tag rischia di catturare solo una frazione del supporto ricevuto. La regola diventa difficile da applicare in modo coerente.

Chi perde da questa rimozione? Chiunque debba fare auditing della supply chain del kernel. I tag di provenienza come "Assisted-by" offrono un indizio a basso costo sulla natura di una modifica. Senza di essi, la responsabilità si sposta su analisi più invasive, come la revisione manuale approfondita o sistemi di monitoraggio dei pattern di codice. Le organizzazioni che eseguono il kernel in ambienti regolamentati, o che gestiscono infrastrutture self-hosted per motivi di sovranità dei dati, potrebbero trovarsi con meno informazioni per valutare il rischio. Il costo dell'audit non scompare: si sposta dalla comunità del kernel alle singole organizzazioni.

Al tempo stesso, la mossa segnala la normalizzazione dell'uso dei LLM nello sviluppo. La domanda non è più se un LLM è stato usato, ma se il codice risultante è corretto, mantenibile e sicuro. Questo sposta l'attenzione dal produttore al prodotto. In un certo senso, è un riconoscimento che la revisione tecnica deve basarsi sul codice, non sulla narrativa di come è stato scritto.

Ma questo approccio ha un problema: i revisori del kernel lavorano già con risorse limitate. Se il tag sparisce, perdono un segnale che poteva indirizzare l'attenzione verso modifiche generate sinteticamente. Non tutti i contributi assistiti sono di qualità inferiore, ma sapere che un LLM ha avuto un ruolo aiuta a cercare categorie di errori tipiche dei modelli generativi. Rimuovere il tag non elimina quei rischi: li rende più opachi.

La comunità del kernel Linux è abituata a decisioni di governance pragmatiche. Ma eliminare l'obbligo di dichiarare l'uso di LLM arriva in un momento in cui la trasparenza della supply chain è diventata una priorità per governi e aziende. La domanda aperta è se strumenti automatici di rilevamento riempiranno il vuoto lasciato dal tag, o se l'ecosistema accetterà una minore tracciabilità. Per chi valuta deployment on-premise, il nodo è concreto: il kernel è la base su cui si costruisce la fiducia nell'infrastruttura, e i trade-off tra trasparenza del software e velocità di sviluppo non sono secondari. AI-RADAR approfondisce questi temi con framework analitici su /llm-onpremise.