È arrivata anche questa settimana la notizia di un nuovo sistema operativo scritto quasi interamente da agenti AI. La fonte racconta di un progetto finito nella casella email della redazione: l'ennesimo OS "codificato da zero" con le capacità odierne di LLM e AI. La maggior parte di questi esperimenti è open-source, ma questo specifico progetto si presenta chiuso, con una giustificazione: la sicurezza.

La cadenza con cui compaiono questi annunci è ormai un dato strutturale. Non si tratta di valutare se uno di questi sistemi diventerà il prossimo Linux; il punto è che i modelli generativi hanno abbassato a tal punto il costo di produrre codice di sistema plausibile da trasformare la creazione di un OS in un artefatto quasi settimanale. Ma un sistema operativo non è una demo: gestisce memoria, permessi, driver, isolamento dei processi. La sicurezza non è una proprietà che si aggiunge alla fine, è il modo in cui questi componenti vengono progettati e verificati.

La chiusura non è una prova di sicurezza

La scelta di tenere chiuso il codice in nome della sicurezza merita di essere osservata con attenzione. Nel software tradizionale, il codice chiuso può proteggere dettagli implementativi e ridurre la superficie di attacco nota, ma non rende automaticamente un sistema più sicuro. Anzi, nasconde la possibilità di verificare cosa fa davvero il codice. In un contesto in cui il codice è generato in modo massiccio da agenti AI, il problema si sposta: nessun essere umano ha scritto riga per riga ogni percorso critico. L'audit diventa più importante, non meno. Chiudere il sorgente in nome della sicurezza può essere una posizione legittima se accompagnata da revisione indipendente, ma usata da sola rischia di trasformarsi in un argomento per evitare controlli.

Il nodo per chi valuta stack locali e sovranità

Per le organizzazioni che valutano deployment on-premise o self-hosted, la notizia segnala un cambiamento nei termini della fiducia. Quando un sistema operativo arriva da una pipeline di generazione automatica, la verifica non può limitarsi al binario: occorre risalire alla provenienza del modello, ai dati usati per il fine-tuning, all'ambiente in cui gli agenti hanno operato. Un OS chiuso generato da AI sposta l'onere della prova: chi lo adotta deve fidarsi della parola del fornitore, senza poter ispezionare le scelte fatte dagli agenti. Questo ha implicazioni di secondo ordine per la sovranità dei dati e per il TCO: la mancanza di accesso al codice può ridurre i costi immediati, ma aumenta il rischio di dipendenza e di incidenti non diagnosticabili.

Non è un caso che la maggior parte di questi progetti nasca open-source. La comunità che sperimenta con OS generati dall'AI sembra preferire la trasparenza, sia per imparare sia per correggere. L'eccezione chiusa in nome della sicurezza diventa quindi un test: se la chiusura viene accettata dal mercato, si normalizza l'idea che un componente critico generato da AI possa essere distribuito senza possibilità di audit. Se invece prevale la richiesta di trasparenza, la sicurezza dovrà essere dimostrata con strumenti diversi: attestazioni, build riproducibili, report di valutazione. In entrambi i casi, il fenomeno sposta il centro di gravità dalla revisione del codice alla governance dei modelli.