Dalla macchina alla mente: perché servono nuovi sistemi operativi per l’Intelligenza Artificiale
Ogni rivoluzione digitale è nata da un cambio di linguaggio, sempre accompagnato da un nuovo approccio al sistema operativo. Se osserviamo bene, negli anni ’70, Unix portò ordine e gerarchia dove era necessario costruire il futuro su solide basi. Negli anni ’90, era il tempo del PC per tutti e Windows rese la tecnologia universale e accessibile a tutti, anche ai non tecnici. Quando poi ci si rese conto che un Sistema Operativo era anche un modo di pensare, Linux, con la sua etica della libertà, aprì la via all’open-source. Ognuno di questi sistemi ha tradotto un modo di pensare nel rapporto fra uomo e macchina. Ma oggi, qualcosa è cambiato in modo radicale: nuovi sistemi, nuovi paradigmi e, come sempre, nuove necessità da affrontare. L’Intelligenza Artificiale non è più un programma qualunque che gira sopra un sistema operativo: è diventata essa stessa un sistema “vivente di processi cognitivi”. Modelli che apprendono, comunicano, decidono (in modo sempre più autonomo) e si adattano alle condizioni esterne e al contesto. Un’AI moderna non “esegue istruzioni”, ma genera inferenze, strategie, relazioni e nessun OS tradizionale — progettato per gestire file, memoria e input utente e dispositivi hardware — è in grado di sostenere questa nuova complessità relazionale. Abbiamo quindi bisogno di nuovi sistemi operativi1: non più piattaforme per computer, ma habitat cognitivi per intelligenze. Spazi dove il calcolo si intreccia con la percezione, dove la decisione è un processo distribuito e dinamico, dove l’etica e la memoria diventano parti strutturali del kernel stesso. In questo scenario, che poi non è altro che lo specchio tecnologico della società attuale, emergono quattro grandi famiglie di sistemi operativi che potremo definire “per l’Intelligenza”, ognuna portatrice di una visione diversa del rapporto tra tecnica e coscienza. I primi embrioni di questa nuova famiglia di OS nascono nei laboratori di ricerca: da Singularity OS di Microsoft Research ai recenti esperimenti di AIOS (2024), progettati per gestire stati cognitivi invece di semplici processi. Il kernel non assegna più cicli di CPU, ma compiti cognitivi: inferenze, ragionamenti, interazioni semantiche. È un cervello distribuito, capace di memorizzare contesti, tracciare intenzioni e orchestrare modelli neurali in tempo reale. Nell’ambito militare, industriale e robotico, emergono sistemi pensati per governare sciami intelligenti di droni o agenti digitali. Soluzioni come Anduril Lattice OS o Shield AI Hivemind EdgeOS5 gestiscono flotte autonome con logiche di cooperazione e adattamento continuo. In questi sistemi l’intelligenza è distribuita: ogni unità comunica, apprende e reagisce in rete, senza un centro di comando fisso. È la versione operativa di quella che potremmo definire una ‘mente distribuita’: un ecosistema dove ogni nodo contribuisce alla decisione collettiva. Nel mondo cloud e dell’automazione cognitiva, giganti come Google, AWS e Microsoft stanno costruendo ambienti dove l’agente è l’utente. Vertex AI Agent Engine, Bedrock Agents e il nuovo Microsoft Agent Framework non sono esclusivamente al servizio dello sviluppatore umano ma coordinano intelligenze artificiali che collaborano tra loro, pianificano e ricordano. Questi sistemi incarnano un nuovo paradigma operativo, in cui ogni AI ha la propria memoria, il proprio obiettivo, la propria etica. Non eseguono comandi: dialogano. Infine, il confine tra digitale e materia si assottiglia, ed ecco allora i sistemi operativi di confine: ROS 2, NVIDIA Holoscan, QNX o VxWorks sono le fondamenta su cui si muovono robot, auto autonome e infrastrutture critiche. Qui la sfida è il tempo reale: la decisione e azione quasi contemporanee. Questi OS sono lo scheletro della nuova intelligenza fisica, dove l’AI lascia il cloud e scende nel mondo sensoriale. Tutti questi percorsi convergono verso un’idea comune: un sistema operativo capace non solo di calcolare, ma di comprendere il perché del calcolo e soprattutto le conseguenze di una decisione. Un OS che integri logiche di fiducia, memoria contestuale, responsabilità. Un tale sistema operativo sarà dotato di una sorta di ‘registro etico’ inscritto nel codice, in cui ogni azione è tracciata non solo per efficienza, ma anche per garantire trasparenza e responsabilità. La domanda iniziale, dunque, trova la sua risposta nella trasformazione stessa: non abbiamo più bisogno di un sistema operativo per le macchine, ma di un sistema operativo per le menti artificiali. Uno spazio dove la tecnologia e la coscienza possano finalmente coabitare, come due processi che imparano, insieme, a condividere la stessa memoria. Nei prossimi paragrafi esploreremo alcuni di questi nuovi sistemi operativi dell’Intelligenza Artificiale, osservando come la tecnica, ancora una volta, si stia evolvendo in direzioni non ancora del tutto prevedibili, ma senza dubbio affascinanti. Le architetture operative che conosciamo oggi — da Windows a Linux — si fondano tutte sullo stesso principio: il sistema operativo gestisce risorse fisiche e logiche, come CPU, memoria e processi. Ma quando i “processi” diventano “neuroni digitali“, quel modello inizia a scricchiolare. Un Neuro-OS nasce esattamente per questo: sostituire la logica della gestione delle risorse con quella della gestione dell’intelligenza. Il suo compito non è più assegnare tempo di calcolo a un thread, ma coordinare attività di ragionamento, inferenza, memoria contestuale e adattamento continuo. In un certo senso, il kernel — il cuore del sistema operativo — si trasforma da direttore d’orchestra di istruzioni a coordinatore di reti neurali. L’idea non è nuova. Già nel 2004 Microsoft Research sperimentò Singularity OS, un progetto pensato per creare un sistema operativo completamente scritto in codice gestito2, con processi isolati ma comunicanti attraverso canali di memoria sicuri. L’obiettivo era semplice e ambizioso: garantire affidabilità e auto-controllo a ogni processo. Non era ancora un OS “intelligente”, ma introduceva per la prima volta un concetto fondamentale per l’AI moderna: processi autonomi che conoscono il proprio stato. Anni dopo, nel 2015, nacque il Neurokernel Project della Columbia University — avviato da Aurel A. Lazar — piattaforma open-source per emulare il cervello della Drosophila su GPU: il “kernel” coordina moduli neurali e interfacce tra neuropili, anticipando OS che orchestrano reti neurali in tempo reale. Nel progetto il kernel non gestiva file o driver, ma “sinapsi digitali”, con funzioni dedicate alla comunicazione tra moduli neuronali. Un esperimento che, pur confinato alla ricerca, ha aperto la strada all’idea di un sistema operativo capace di orchestrare reti neurali in tempo reale. Nel 2024, la Rutgers University (USA) ha presentato AIOS — LLM Agent Operating System —, probabilmente il primo tentativo reale di costruire un sistema operativo progettato nativamente per agenti di intelligenza artificiale. AIOS introduce un concetto che potremmo chiamare “cognitive scheduling”: il kernel decide non solo quale processo eseguire, ma quale obiettivo prioritario perseguire, bilanciando memoria, contesto e risorse semantiche. Un passo avanti rispetto ai runtime classici, che trattano i modelli come semplici applicazioni. In un sistema operativo tradizionale, le risorse sono assegnate in base a criteri di efficienza; in un Neuro-OS, le risorse sono gestite in base al significato delle operazioni. Se un modello linguistico deve analizzare un contesto complesso o rispondere in tempo reale, il kernel può allocare priorità cognitive, non solo computazionali. Questa visione apre la strada a un nuovo modo di intendere l’operatività dell’AI: In termini pratici, significa costruire un’infrastruttura dove le AI non vengono eseguite, ma vivono in esecuzione continua, mantenendo uno stato, un obiettivo e un grado di autonomia misurabile. La nascita di questi sistemi porta con sé sfide tecniche e strategiche. In primo luogo consideriamo l’aspetto della sicurezza: un kernel che gestisce reti neurali deve impedire che un modello compromesso influenzi l’intero sistema. In secondo luogo occorre approfondire gli aspetti di governance: chi controlla le priorità di calcolo, gli aggiornamenti dei modelli e la persistenza della memoria? Infine non possiamo certo trascurare la trasparenza: il kernel dovrà registrare decisioni e motivazioni, creando un log leggibile e auditabile — una sorta di “registro etico” integrato — questo perchè vi sarà sempre più la necessità di capire cosa è successo e il perchè di una determinata decisione. Il Neuro-OS è quindi la base della prossima generazione di infrastrutture cognitive: non un sistema che ospita l’AI, ma un sistema pensato, progettato e realizzato per l’AI. Quando la “macchina” non è più un singolo sistema ma decine o centinaia di unità che cooperano — droni, sensori, veicoli, nodi edge — serve uno strato operativo capace di tenere insieme missione, percezione e decisione anche quando i collegamenti si degradano. È qui che entra in gioco lo Swarm OS: non un semplice middleware, ma un’architettura che coordina obiettivi, comunicazioni e ruoli sul campo, mantenendo l’operatore all’interno del ciclo decisionale (on-the-loop) e permettendo nel contempo all’autonomia locale (uno o più elementi periferici) di reggere l’urto della realtà. L’immagine più chiara arriva da Lattice, la piattaforma di Anduril descritta dall’azienda come un “open operating system for defense”: un livello software che unifica comando e controllo, autonomia e fusione dati su asset eterogenei e multi-dominio, con un’attenzione esplicita alla scalabilità JADC23. In pratica, è un OS che “vede” e governa sciami e famiglie di sistemi diversi come un’unica capacità operativa, dalla periferia al centro decisionale. Sul fronte delle missioni autonome, Shield AI ha sviluppato Hivemind, un autonomy stack4 che consente a velivoli e droni di pianificare e volare in modo collaborativo. Il passo successivo è EdgeOS, un software che porta quella stessa autonomia su piattaforme differenti: un middleware pensato per la periferia, con hard real-time dove serve e con capacità di recupero quando il link si interrompe. Le dimostrazioni più recenti includono l’integrazione su Do-DT255 con Airbus e il volo autonomo in ambienti degradati: un caso concreto di come l’autonomia di sciame possa spostarsi rapidamente da un vettore all’altro senza riscrivere tutto daccapo. Nel mondo open/dual-use, Auterion parte da AuterionOS e introduce Nemyx, un motore che abilita sciami coordinati anche su più produttori: l’idea è trasformare singoli droni in un sistema cooperante tramite upgrade software, sincronizzando targeting, ingressi ed uscite di più unità in uno scenario complesso. Sotto la linea dell’autonomia di sciame, spesso vive l’“OS di volo” PX4, il progetto open-source che fornisce controllo, driver e middleware di base per Unmanned Vehicles6 aerei e non solo. Non è uno Swarm OS, ma è la base tecnica su cui molte soluzioni di sciame appoggiano i comandi di basso livello, accelerando la portabilità del comportamento cooperativo su piattaforme diverse. Il quadro, in prospettiva, è stato accelerato anche dai programmi pubblici come DARPA OFFSET, che hanno codificato interfacce, tattiche e toolchain per sciami fino a 250 unità in ambienti urbani: un banco di prova che ha reso più matura la relazione tra autonomia distribuita e teaming con l’operatore. Ciò che distingue davvero uno Swarm OS da un normale stack di controllo è la percezione condivisa come risorsa di sistema (mappe, minacce, target che “circolano” tra i nodi), la pianificazione distribuita (chi fa cosa, dove e quando, senza un singolo punto di comando), e la resilienza by design: se il link salta, il gruppo non si ferma, ma degrada in modo controllato, rispettando regole e priorità definite in partenza. A questo si aggiungono audit e tracciabilità: log leggibili post-missione che permettono di ricostruire decisioni e prestazioni, requisito essenziale in difesa ma utile anche nei settori industriali più sensibili. In sintesi, lo Swarm OS è il passaggio dal “pilotare cose” al “governare capacità”. Apre la porta a flotte che si comportano come un solo sistema, senza rinunciare al controllo umano e con una base tecnica che, quando possibile, resta aperta e portabile. Nel prossimo passo guarderemo al lato speculare nel cloud: gli Agent-Centric OS, dove l’“utente” non è più una persona alla tastiera, ma un insieme di agenti che cooperano per obiettivi. Se nello Swarm OS l’unità di base è il veicolo o il nodo edge, qui l’unità di base è l’agente: un sistema intelligente capace di ragionare su obiettivi, usare strumenti, collaborare con altri agenti e con l’operatore umano quando serve. Un Agent-Centric OS è lo strato che li fa nascere, li fa parlare tra loro e li governa come un sistema unico, dal cloud fino ai servizi aziendali. In questo modello “l’utente” non è più necessariamente una persona davanti alla tastiera: è un insieme di agenti coordinati che svolgono compiti, prendono decisioni operative e passano il testimone l’uno all’altro. L’esempio più netto è Vertex AI Agent Engine: Google lo presenta come runtime gestito per costruire e far girare agenti che integrano modelli, azioni e dati. Per chi lavora in produzione significa avere un motore unico che incapsula orchestrazione, stato e accesso alle risorse senza inventarsi infrastrutture ad hoc ogni volta. Sul lato AWS, la direzione è simile: Bedrock Agents introduce la collaborazione multi-agente come funzione di piattaforma. Significa poter progettare reti di agenti che si dividono flussi complessi di operazioni, con gestione centralizzata delle risorse e dei permessi, dentro la stessa cornice di sicurezza e dati dell’account AWS. È il passo che porta dai “bot isolati” a squadre di agenti che operano nel rispetto di ben definiti criteri e ruoli. Nel mondo Microsoft, la traiettoria converge: l’Agent Framework unifica l’esperienza di Semantic Kernel e AutoGen7 in un kit open-source per agenti e flussi multi-agente. È una base unica su cui costruire agenti conversazionali, agenti “tool-use”, orchestrazioni a eventi e scenari ibridi (man-in-the-loop), con un’attenzione esplicita alla componibilità del sistema. Per chi ha usato AutoGen, è il naturale “ponte” verso una piattaforma più organica. Fuori dai grandi cloud, l’ecosistema open si muove veloce. CrewAI spinge verso un modello “snello” in cui si progettano agenti con ruoli e obiettivi chiari, memoria e guardrail integrati, e si orchestrano crew di agent che cooperano su compiti end-to-end. È il laboratorio ideale per capire in piccolo ciò che i grandi stanno industrializzando. Sul fronte enterprise, Palantir AIP si posiziona come strato operativo per azioni e agenti collegati ai dati e ai processi: la tesi è che “dati + modelli + operazioni” formino un vero sistema operativo aziendale per flussi decisionali e automazioni governabili. È un approccio top-down che parla il linguaggio del mondo IT: policy, auditing, deployment ed infine integrazione con i sistemi esistenti. In breve, gli Agent-Centric OS sono importanti perchè, in primo luogo, riducono l’attrito d’integrazione. Un agente non è solo un prompt, è gestione di contesto, tool, credenziali, memoria e ruolo, e farlo bene per decine di agenti richiede un sistema che standardizzi tutto questo. Secondo: abilitano la collaborazione. Le piattaforme nate per un singolo “assistant” ora orchestrano squadre di agenti che si passano sottocompiti e verifiche reciproche, alzando l’asticella della qualità. Terzo: portano governance. Audit, policy, controllo degli accessi e dei confini dei dati non sono più un’aggiunta ma parti del “kernel” applicativo che fa girare gli agenti. C’è poi il tema delle interfacce con il mondo reale: un Agent-Centric OS efficace non vive solo nel dialogo testuale ma espone “azioni” verso API, database, strumenti e — quando serve — verso l’edge. È qui che il cerchio si chiude con il capitolo precedente: squadre di agenti nel cloud che coordinano sciami di sensori/attuatori edge, ciascuno padrone nel proprio ambiente ma con un linguaggio comune per obiettivi, stato e risultati. In controluce si vede la stessa trasformazione che abbiamo descritto all’inizio dell’articolo: dal programma al comportamento. Gli Agent-Centric OS prendono ciò che prima era un insieme di script e microservizi e lo elevano a sistema di obiettivi, con strumenti per farlo collaborare, ricordare e rendere conto delle sue azioni. Non è filosofia, è ingegneria dell’operatività: meno attrito, più coordinamento, più controllo. Quando l’AI esce dal datacenter e incontra il mondo – una linea di produzione, un veicolo, una sala operatoria, un cantiere – la regola cambia: non conta soltanto “quanto calcoli”, conta quando lo fai. È la differenza tra un sistema che “ragiona” bene e uno che agisce in tempo, senza sbagliare. Qui vivono gli Edge & Real-Time OS: sistemi operativi e stack che portano l’AI vicino al sensore, con latenza prevedibile, determinismo e sicurezza funzionale. Il cuore del problema è semplice da dire e complesso da realizzare: in molti casi non basta essere veloci in media, bisogna essere puntuali sempre. Un robot che afferra un oggetto, un UAV che evita un ostacolo, un braccio che coopera con un essere umano non possono permettersi ritardi, devono agire quando è necessario, né prima né dopo. Da qui la distinzione tra soft real-time (qualche scostamento è tollerato) e hard real-time (lo scostamento non è accettabile). Gli OS per l’intelligenza fisica combinano quindi tre ingredienti: uno strato real-time affidabile, una pipeline di percezione-pianificazione-controllo ottimizzata per l’ambiente di lavoro e un perimetro di safety che definisce cosa succede quando qualcosa va storto. Sul piano del middleware, il riferimento è ROS 2: non è “un OS” in senso stretto ma lo strato operativo standard della robotica moderna, ROS infatti significa “Robot Operating System”. ROS 2 è il “tessuto di messaggi” che permette alle varie componenti del robot — sensori, motori e software — di parlarsi automaticamente e in modo affidabile, regolando tempi e certezza dei messaggi, così componenti anche di marche diverse funzionano insieme senza reinventare tutto. Intorno a ROS 2 ruotano acceleratori come Isaac/Isaac ROS e gli SDK Jetson/JetPack che portano l’inferenza8 vicino alla camera o al LIDAR9, ottimizzando memoria e throughput senza perdere controllo su tempi e priorità. Quando serve streaming deterministico su flussi ad alta banda – immagini, video, segnali medici – entrano in gioco runtime “a grafo” che schedulano gli operatori come fossero stadi di una catena di montaggio, così ogni frame attraversa la pipeline con latenza nota in anticipo. Quando il requisito non è solo prestazionale ma di sicurezza entra in scena la scuola RTOS10: microkernel, partizionamento rigoroso, certificazioni di safety. QNX e VxWorks sono i nomi storici: architetture pensate per gestire l’errore critico in modo sicuro e isolato, con canali di comunicazione analizzati a priori e con strumenti che costruiscono passo dopo passo un “fascicolo di sicurezza” (safety case) verificabile, raccolgono requisiti, progetto, test ed evidenze in un unico dossier che dimostra in modo tracciabile che il sistema è sicuro. Sono ambienti dove la prevedibilità del comportamento conta più della performance e in cui l’AI va controllata con modalità di degradazione predisposte. Ancora più in profondità, su microcontrollori e sensori intelligenti, vive l’ecosistema Zephyr11 + TensorFlow Lite Micro: potenza e latenza bassissima e logiche di pre-filtraggio che alleggeriscono il carico computazionale. Il punto cruciale è l’integrazione perchè un Edge OS efficace non vive da solo: deve parlare con lo Swarm OS che coordina più unità e con l’Agent-Centric OS che guida la missione dal cloud. Significa esporre stato, obiettivi, eventi con la stessa semantica su tutti i livelli. Un alert generato da un dispositivo periferico deve essere immediatamente “comprensibile” dagli agenti in cloud, una variazione di piano decisa dal coordinatore deve propagarsi come vincolo real-time fino al controllore di bordo. In mezzo, c’è il lavoro sporco ma decisivo: schedulare GPU e CPU senza jitter12 e senza conflitti tra percezione e controllo; gestire la memoria perché i buffer dei sensori non affoghino i planner; chiudere i cicli di controllo nel tempo assegnato; registrare ciò che è accaduto con log leggibili a prova di audit. Infine, c’è la safety by design. L’AI all’edge non è mai sola: attorno ci sono guardrail che definiscono limiti fisici, geofence, piani di arresto, fallback automatici. Se la rete cade, si passa al piano B locale; se l’inferenza degrada oltre soglia, si riduce la manovra; se il sensore impazzisce, si isola il modulo e si porta il sistema in stato sicuro. È una mentalità da ingegneria dei sistemi: entusiasmo sì, ma con strumenti di verifica, prove di resilienza e un perimetro di responsabilità chiaro. In breve, l’Edge & Real-Time è il luogo dove l’AI diventa comportamento fisico. Qui si misurano non solo i parametri di accuratezza, ma quelli di affidabilità: quante volte rispetti la scadenza, quanto prevedibile è la latenza, quanto bene degradi quando il mondo non collabora. È il banco di prova che separa la demo dal prodotto. In chiusura, se volessimo riassumere il nostro viaggio in poche righe potremmo dire che abbiamo seguito quattro traiettorie che in realtà sono un’unica architettura: il Neuro-OS che organizza compiti intelligenti, lo Swarm OS che coordina flotte e capacità, l’Agent-Centric OS che governa squadre di agenti nel cloud e l’Edge & Real-Time OS che porta le decisioni nel mondo fisico con tempi garantiti. A volte sono veri sistemi operativi, altre volte runtime o stack, ma l’effetto complessivo è lo stesso: un livello operativo per l’intelligenza. L’idea di fondo è pratica: spostare il baricentro dal calcolo al comportamento. Non basta avere un modello che “sa”, serve un sistema che coordina, registra, risponde e se occorre decide, con i vincoli del contesto applicativo in cui è immerso. Per questo parliamo di “habitat” per AI: luoghi software dove obiettivi e risorse si incontrano, con memoria, auditing e regole chiare. Nel prossimo futuro la differenza non la faranno i singoli record di benchmark ma la capacità di orchestrare. Chi saprà unire questi quattro strati — dal kernel cognitivo al bordo — avrà sistemi che non solo funzionano, ma si comportano bene: prevedibili quando serve, flessibili quando possibile, trasparenti quando è necessario. È qui che la macchina incontra la mente e “vive” il mondo. Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione. Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica. C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale. Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/
redhotcyber.comOct 16, 2025extracted