Nel merge del sottosistema input per il ciclo Linux 7.3 non sono entrati soltanto nuovi driver o piccoli ritocchi. Il pacchetto include una serie di correzioni di sicurezza e migliorie, e una parte di queste segnalazioni arriva da un flusso di scoperte generate con l'aiuto di LLM. È un dettaglio che merita più attenzione del solito: non stiamo parlando di un esperimento isolato, ma di contributi che finiscono in un componente del kernel usato da tastiere, mouse, touchscreen, sensori e controller di gioco su qualunque distribuzione Linux.

Il sottosistema input è uno dei punti in cui la varietà hardware si sente di più. Ogni periferica ha percorsi di inizializzazione, gestione degli eventi e cleanup specifici; gli errori in queste aree si trasformano facilmente in blocchi, accessi errati alla memoria o comportamenti difficili da riprodurre. La revisione umana, per quanto rigorosa, non riesce a coprire tutte le combinazioni di hardware e firmware in circolazione. In questo scenario, usare gli LLM per analizzare porzioni di codice e suggerire anomalie non è una scorciatoia: è un modo per aumentare la superficie controllata, lasciando ai maintainer il compito di filtrare le segnalazioni valide.

La tesi che emerge è strutturale. Gli LLM stanno diventando un ingranaggio della manutenzione del kernel, non un sostituto dei revisori. La scoperta generata da un modello non arriva come patch pronta, ma come candidata da verificare. Chi pensa che l'automazione riduca il lavoro degli esperti umani guarda la metà sbagliata del processo: il collo di bottiglia si sposta dalla segnalazione iniziale alla capacità di distinguere un vero problema da un falso positivo. Questa capacità diventa più preziosa, non meno.

Per chi gestisce infrastrutture self-hosted, la ricaduta è concreta. I sistemi industriali, i chioschi, i dispositivi embedded e le installazioni air-gapped spesso usano controller di input non standard o versioni di driver poco testate. Correggere prima una vulnerabilità in quei percorsi riduce il tempo in cui un sistema isolato ma fisicamente accessibile resta esposto. Allo stesso tempo, la stessa tecnicia LLM può essere eseguita localmente per analizzare patch, moduli o configurazioni del kernel prima del deploy, senza inviare codice o log a servizi esterni. Non è un aspetto secondario per chi deve rispettare vincoli di sovranità dei dati o semplicemente vuole evitare che codice proprietario esca dalla rete aziendale. Per chi valuta deployment on-premise, esistono trade-off tra costo di gestione dei modelli locali e controllo dei dati; AI-RADAR offre framework analitici su /llm-onpremise per inquadrarli.

Il merge non dice quanti fix derivino dagli LLM, né quali modelli li abbiano generati. Ma il fatto che siano arrivati fino all'albero principale sposta la domanda: non se l'AI assisterà la revisione del kernel, ma quanto in fretta diventerà parte della routine.