Da qualche anno, se un agente basato su Large Language Models interviene nella scrittura di una patch per il kernel Linux, le policy richiedono di indicarlo esplicitamente con un tag "Assisted-by" nel corpo del commit. Una traccia minima, pensata per rendere trasparente l’origine del codice e permettere ai manutentori di valutare con attenzione le contribuzioni. Questa settimana, però, gli sviluppatori hanno riaperto la discussione: si può semplificare quella regola, o magari abbandonarla del tutto?

La conversazione, emersa sulle mailing list del progetto, non ha ancora prodotto una decisione, ma sta già facendo emergere posizioni contrastanti. C’è chi considera il tag un orpello burocratico ormai superato, perché gli strumenti di assistenza basati su LLM sono sempre più integrati nel workflow quotidiano e distinguere un suggerimento automatico da una modifica manuale è diventato artificiale. Altri, invece, difendono l’attribuzione come presidio minimo di fiducia in una codebase che tocca il cuore di infrastrutture critiche planetarie.

La questione apparentemente tecnica tocca in realtà un nodo che AI‑RADAR esplora regolarmente: il rapporto tra automazione e sovranità del codice. Quando un’organizzazione decide di impiegare modelli on‑premise per accelerare lo sviluppo – per non esporre codice proprietario a servizi esterni – il tema della provenienza diventa ancora più delicato. Non basta sapere che una patch è stata generata: chi la firma si assume la responsabilità legale e ingegneristica di ciò che viene integrato. Per le imprese che costruiscono stack di inference self‑hosted, l’assenza di un meccanismo di attribuzione potrebbe indebolire l’audit trail e rendere più difficile ricostruire decisioni automatiche a posteriori, specialmente in settori regolati dove la tracciabilità dell’intervento umano non è negoziabile.

C’è anche un risvolto legato alla Total Cost of Ownership. Un’infrastruttura on‑premise per LLM viene spesso scelta per minimizzare il rischio di fuga di dati e per garantire conformità GDPR, ma porta con sé la necessità di ridefinire le policy interne sulla proprietà intellettuale. Se il kernel Linux – che opera con un modello di fiducia distribuita storicamente basato sulla reputazione personale – sta discutendo se nascondere l’impronta dell’IA, le aziende che stanno replicando pipeline simili dietro i propri firewall devono chiedersi quali automatismi possono permettersi di silenziare senza erodere la fiducia dei propri audit.

Alcuni manutentori storici ricordano che situazioni analoghe erano già emerse anni fa con le prime estensioni automatiche per il controllo del formato del codice. Allora si decise di mantenere una traccia. Oggi lo scenario è diverso perché l’ampiezza dell’intervento è potenzialmente maggiore: intere funzioni vengono stese da un modello, e il confine tra suggerimento e scrittura autonoma è labile.

La discussione resterà aperta ancora per qualche tempo, e l’eventuale modifica della policy avrà un impatto immediato su migliaia di sviluppatori che contribuiscono quotidianamente al kernel. Nel frattempo, chi governa ambienti di sviluppo enterprise con LLM locali può osservare questo dibattito come un banco di prova: le decisioni prese da uno dei progetti open source più rigorosi al mondo sulla trasparenza dell’automazione serviranno da riferimento per le proprie pratiche. Non si tratta solo di conformità formale, ma della capacità di governare una pipeline in cui il codice non nasce più esclusivamente dalla tastiera di una persona.