Quando si parla di intelligenza artificiale quantistica, l’attenzione si concentra generalmente sugli algoritmi e sull’hardware: numero di qubit, tasso di errore, tempo di coerenza, profondità dei circuiti. Sono parametri essenziali, ma descrivono soltanto una parte del problema.
Con IA quantistica ci riferiamo qui, più precisamente, al quantum machine learning: sistemi nei quali alcune fasi di un processo di apprendimento automatico impiegano circuiti, simulatori o processori quantistici.
Nelle applicazioni realistiche, tuttavia, il modello quantistico non opera isolatamente. I dati devono essere acquisiti, puliti e trasformati con strumenti classici; l’ottimizzazione dei parametri viene spesso eseguita da CPU o GPU; risultati, configurazioni e modelli devono essere registrati, confrontati e distribuiti attraverso infrastrutture software convenzionali.
Il futuro del quantum machine learning sarà quindi, almeno nel medio periodo, prevalentemente ibrido. Il processore quantistico non sostituirà il cloud o i sistemi di calcolo ad alte prestazioni, ma diventerà una risorsa specializzata all’interno di infrastrutture distribuite nelle quali CPU, GPU, simulatori e unità di elaborazione quantistica, le QPU, cooperano nello svolgimento dello stesso processo.
La sovranità quantistica non dipenderà soltanto dalla disponibilità di QPU, ma dal controllo dell’intero stack, dalla diffusione delle competenze, dalla possibilità di evitare dipendenze irreversibili e dalla capacità di trasformare i risultati della ricerca in sistemi realmente utilizzabili.
Indice degli argomenti
Quantum MLOps dalla sperimentazione alla messa in esercizio
In un laboratorio è possibile eseguire manualmente un circuito, modificare alcuni parametri, raccogliere il risultato e ripetere l’esperimento. Quando però il modello deve essere utilizzato regolarmente, confrontato con altre versioni o inserito in un servizio, questo modo di procedere non è più sufficiente.
Occorre sapere quale versione dei dati è stata utilizzata, con quali parametri è stato addestrato il modello, su quale dispositivo è stato eseguito il circuito e quali trasformazioni sono state applicate. Bisogna inoltre poter ripetere l’esperimento, distribuire il modello in un ambiente diverso e verificare che la versione messa in esercizio corrisponda effettivamente a quella valutata.
Il passaggio dalla sperimentazione alla messa in esercizio richiede quindi una gestione completa del ciclo di vita. Nel machine learning tradizionale questa esigenza ha portato allo sviluppo del MLOps, che applica ai modelli di apprendimento automatico principi già consolidati nell’ingegneria del software: automazione, versionamento, integrazione continua, distribuzione controllata, monitoraggio e tracciabilità.
Nel quantum machine learning gli stessi principi devono essere estesi a un ambiente più eterogeneo e meno prevedibile. La preparazione dei dati può essere eseguita su CPU, l’addestramento può alternare ottimizzazione classica ed esecuzione quantistica, mentre l’inferenza può utilizzare una QPU reale, un simulatore accelerato oppure, in caso di indisponibilità, una soluzione alternativa.
Il Quantum MLOps non consiste dunque semplicemente nell’aggiungere una QPU a una piattaforma esistente. Deve coordinare ambienti con caratteristiche radicalmente differenti, alcuni dei quali possono essere remoti, condivisi con altri utenti e amministrati da un provider esterno.
Quantum MLOps e workflow ibridi
Un workflow di machine learning può essere rappresentato attraverso tre fasi principali: preparazione dei dati, addestramento e utilizzo del modello.
Dati, addestramento e inferenza
Nel caso quantistico, ciascuna fase può coinvolgere risorse classiche o quantistiche. I dati possono essere preparati con strumenti convenzionali, ma devono poi essere trasformati in una rappresentazione compatibile con il circuito. L’addestramento può consistere in un ciclo ibrido nel quale la QPU valuta il circuito e un algoritmo classico aggiorna i parametri. Anche il servizio di inferenza può richiedere l’accesso a un backend quantistico.
Queste combinazioni producono workflow diversi, caratterizzati da dipendenze e vincoli operativi differenti. Se il processore quantistico viene impiegato solo durante l’addestramento, il modello potrebbe essere distribuito successivamente su un’infrastruttura classica. Se viene utilizzato anche durante l’inferenza, ogni richiesta applicativa dipenderà invece dalla disponibilità della QPU, dai suoi tempi di coda e dalle condizioni operative del dispositivo.
A questa complessità si aggiunge il ciclo di sviluppo del software. Il codice deve essere verificato, i circuiti devono essere testati attraverso simulatori, gli artefatti devono essere inseriti in container e distribuiti negli ambienti di esecuzione. Le pipeline di integrazione e distribuzione continua rimangono in gran parte classiche, ma devono essere in grado di attivare dinamicamente risorse quantistiche durante l’addestramento o l’inferenza.
Il Quantum MLOps deve pertanto unificare due mondi: da un lato i processi ormai maturi del cloud-native e del machine learning operativo; dall’altro un insieme di dispositivi e servizi quantistici ancora fortemente eterogenei.
Quantum MLOps in una pipeline ibrida
Per verificare concretamente queste esigenze abbiamo sperimentato un’infrastruttura cloud-native per la gestione end-to-end di workflow ibridi di quantum machine learning [1].
La piattaforma utilizza Kubernetes per coordinare le risorse computazionali, Prefect per gestire i workflow, MLflow per registrare esperimenti e modelli, MinIO per conservare dati e artefatti e KServe per distribuire i servizi di inferenza. L’ambiente sperimentale è costituito da un cluster nel quale un nodo è destinato ai carichi classici, mentre un secondo rende disponibili GPU virtualizzate e gateway verso simulatori o dispositivi quantistici.
Il caso della classificazione dello spam
Come caso di studio è stato utilizzato un sistema per la classificazione dello spam basato su Quantum Tensor Network. La preparazione del dataset, con normalizzazione, selezione delle variabili e versionamento, viene svolta su risorse classiche. L’addestramento combina procedure di ottimizzazione tradizionali con l’esecuzione di circuiti quantistici. Il modello selezionato viene infine inserito nel registro e reso disponibile attraverso una pipeline di serving.
La classificazione dello spam non deve essere interpretata come la dimostrazione di un vantaggio quantistico rispetto agli algoritmi classici. Rappresenta piuttosto un banco di prova controllabile, utilizzato per verificare se un modello quantistico possa attraversare tutte le fasi del proprio ciclo di vita — dati, addestramento, registrazione e inferenza — senza perdere riproducibilità e coerenza.
I risultati mostrano che la gestione attraverso la piattaforma MLOps non modifica sostanzialmente il comportamento predittivo dei modelli considerati. Accuratezza, precisione, richiamo e F1-score risultano equivalenti nelle esecuzioni gestite e in quelle non orchestrate.
Il confronto dei tempi di esecuzione richiede invece maggiore prudenza. L’ambiente orchestrato dispone di risorse cluster più robuste rispetto al computer personale utilizzato per l’esecuzione non gestita. Le differenze osservate non possono quindi essere attribuite al MLOps in quanto tale. Il risultato più corretto è che le operazioni di tracciamento, versionamento e orchestrazione non introducono un degrado tale da annullare i vantaggi dell’infrastruttura, non che il Quantum MLOps produca autonomamente uno speedup.
Il risultato più interessante emerge invece osservando il comportamento complessivo del workflow.
Scheduler e code nel Quantum MLOps
In una pipeline ibrida operano almeno tre sistemi distinti di scheduling.
Il primo è quello del provider quantistico, che governa l’accesso alle QPU. Il secondo è lo scheduler di Kubernetes, che assegna i container ai nodi classici o accelerati. Il terzo è il workflow scheduler, nel nostro caso Prefect, che stabilisce quando avviare le diverse attività.
Ciascuno prende decisioni localmente ragionevoli sulla base delle informazioni disponibili. Il problema è che nessuno possiede una visione completa dello stato degli altri. Prefect può avviare una fase di elaborazione senza sapere che il backend quantistico richiesto ha una lunga coda. Kubernetes può assegnare CPU, memoria o GPU a un container che rimarrà inattivo in attesa del risultato della QPU. Il provider quantistico, a sua volta, può completare numerosi job in un intervallo molto breve, provocando un’improvvisa ondata di attività nei livelli superiori.
L’amplificazione delle code
Si produce così una forma di amplificazione delle code. Un ritardo nell’accesso alla QPU si propaga verso l’alto, blocca il workflow e mantiene allocate risorse classiche che non possono proseguire. Quando diversi job quantistici terminano quasi contemporaneamente, il problema si rovescia e genera un picco di richieste verso Kubernetes e il workflow manager.
La sperimentazione ha evidenziato tre possibili conseguenze:
• tempi di attesa che si propagano tra i diversi livelli;
• sottoutilizzo delle risorse classiche già allocate;
• carichi improvvisi generati dal completamento asincrono dei job quantistici.
L’orchestrazione diventa pertanto un problema centrale, non un servizio accessorio. Non è sufficiente ottimizzare separatamente ogni scheduler: occorre coordinare decisioni prese in domini amministrativi differenti.
Una piattaforma realmente consapevole delle risorse quantistiche dovrebbe conoscere almeno la disponibilità stimata dei backend, i tempi delle code, le caratteristiche dei dispositivi e i requisiti dei circuiti. Dovrebbe inoltre poter ritardare l’allocazione delle risorse classiche, selezionare un backend alternativo o modificare il piano di esecuzione quando le condizioni cambiano.
Quantum MLOps e riproducibilità degli esperimenti
Nel machine learning classico, la riproducibilità richiede almeno la conservazione del codice, del dataset, dei parametri e della versione del modello. Nel quantum machine learning questo insieme non è sufficiente. Il risultato può dipendere anche dal dispositivo impiegato, dalla sua topologia, dallo stato di calibrazione, dal rumore, dal numero di esecuzioni del circuito, dal compilatore e dalle trasformazioni utilizzate per adattare il circuito all’hardware.
Due esecuzioni dello stesso programma, svolte in momenti diversi sullo stesso backend, possono quindi produrre risultati non perfettamente coincidenti. La variabilità non deriva necessariamente da un errore nel software: può riflettere le condizioni fisiche del dispositivo e la natura probabilistica dell’elaborazione quantistica.
I metadati necessari per riprodurre un esperimento
Per descrivere adeguatamente un esperimento occorre registrare, insieme al modello:
- il backend quantistico o il simulatore utilizzato;
- le versioni degli SDK e degli strumenti software;
- la topologia e lo stato di calibrazione del dispositivo;
- la configurazione del circuito e il processo di transpilation;
- il numero di misurazioni e gli eventuali metodi di mitigazione degli errori;
- i metadati operativi disponibili, compresi i tempi di attesa e di esecuzione.
Il Quantum MLOps assume così una funzione ulteriore: diventa la memoria organizzativa dell’esperimento.
Senza un registro sistematico, una parte rilevante della conoscenza rimane tacita. Risiede nelle configurazioni locali, negli script non documentati e nell’esperienza delle persone che conoscono le peculiarità di un determinato provider. Se queste persone cambiano progetto o lasciano l’organizzazione, la possibilità di riprodurre e mantenere il sistema può andare perduta.
Il tracciamento degli esperimenti non serve quindi soltanto a confrontare metriche. Riduce la dipendenza dalla memoria individuale e trasforma scelte operative sparse in conoscenza condivisa.
Orchestrazione quantistica e decisioni organizzative
Quando una risorsa è rara, costosa, remota e condivisa, lo scheduling non è più soltanto una questione tecnica. La politica di accesso alla QPU determina indirettamente quali gruppi possano eseguire più esperimenti, quali applicazioni abbiano priorità e quali tempi di servizio possano essere garantiti. La visibilità sulle code influenza la pianificazione delle attività, mentre le modalità di tariffazione possono favorire alcuni tipi di utilizzo e scoraggiarne altri.
Occorre allora stabilire chi definisce le priorità, quali informazioni sulla disponibilità vengono condivise, come vengono gestiti i conflitti e chi è responsabile quando il mancato coordinamento provoca ritardi o costi inattesi.
Lo stesso problema si presenta all’interno delle organizzazioni. Se una risorsa quantistica è condivisa tra gruppi di ricerca o unità aziendali, devono essere definiti criteri di allocazione, livelli di servizio e procedure per gestire le richieste concorrenti. Lo scheduler diventa quindi uno dei luoghi nei quali le politiche organizzative vengono tradotte in decisioni operative.
Anche le competenze devono essere ripensate. Una pipeline ibrida coinvolge esperti di machine learning, quantum scientist, data engineer, cloud engineer, responsabili MLOps, specialisti HPC e figure che si occupano di sicurezza e procurement.
La soluzione non può consistere nel trasformare ogni sviluppatore in un fisico quantistico. Servono piuttosto interfacce stabili, linguaggi comuni e responsabilità chiaramente definite. Le piattaforme devono nascondere la complessità non necessaria senza rendere invisibili le decisioni che incidono sul comportamento del sistema.
Interoperabilità dei provider nel Quantum MLOps
L’eterogeneità del settore quantistico non riguarda soltanto l’hardware. Provider diversi adottano SDK, formati, compilatori, servizi cloud e strumenti di gestione differenti.
Una scelta inizialmente sperimentale può quindi trasformarsi rapidamente in una dipendenza strutturale. Gli sviluppatori acquisiscono competenze su un framework, i workflow vengono costruiti intorno alle sue API, gli artefatti sono memorizzati nei suoi formati e i processi organizzativi si adattano alle funzionalità della piattaforma. Cambiare provider non significa più modificare l’indirizzo di un servizio. Può richiedere la riscrittura dei circuiti, la sostituzione degli strumenti di monitoraggio, la riconfigurazione delle pipeline e la formazione del personale.
I pozzi gravitazionali dei provider
Una recente analisi socio-tecnica degli ecosistemi software quantistici descrive alcune tecnologie e pratiche come gravity wells, pozzi gravitazionali che esercitano un’attrazione crescente sulle scelte circostanti. Quanto più strumenti, competenze e processi si concentrano intorno a una piattaforma, tanto maggiore diventa il costo dell’uscita. L’analisi suggerisce quindi di valutare le tecnologie non soltanto per le funzionalità immediate, ma anche per la loro capacità di preservare flessibilità architetturale ed evoluzione futura [2].
La frammentazione dei framework può inoltre limitare la riproducibilità e rendere difficile confrontare lo stesso modello su hardware differenti. Una recente proposta [3], affronta esplicitamente questo problema attraverso una rappresentazione comune, un livello di astrazione dell’hardware e meccanismi di esportazione tra diversi framework e provider. Il fatto stesso che emergano architetture di questo tipo mostra quanto l’interoperabilità sia ormai considerata un requisito per la maturazione del settore.
La portabilità non può essere aggiunta facilmente al termine del progetto. Deve essere progettata fin dall’inizio, separando la logica applicativa dalle interfacce specifiche dei provider e registrando gli artefatti in formati esportabili.
Come diventare quantum-ready con il MLOps
Prepararsi al quantum non significa necessariamente acquistare subito hardware o trasferire applicazioni esistenti su una QPU. Significa creare le condizioni per sperimentare senza costruire dipendenze irreversibili. Un’organizzazione dovrebbe innanzitutto progettare workflow modulari, nei quali il backend possa essere sostituito senza riscrivere l’intera applicazione. Simulatori, QPU e risorse classiche dovrebbero essere accessibili attraverso interfacce chiaramente definite.
Occorre poi adottare una tracciabilità end-to-end. Dataset, circuiti, modelli, configurazioni, versioni dei backend e risultati devono essere considerati artefatti dello stesso processo. È necessaria anche un’osservabilità trasversale. Monitorare separatamente Kubernetes, il workflow manager e la QPU non consente di comprendere come le loro decisioni interagiscano. Servono metriche capaci di ricostruire il percorso completo di un’attività, distinguendo il tempo di calcolo da quello trascorso nelle diverse code.
Fallback, osservabilità e procurement
Devono inoltre essere previste strategie di fallback. Se una QPU non è disponibile o il tempo stimato di attesa supera una soglia accettabile, il sistema dovrebbe poter rinviare l’esecuzione, scegliere un altro backend, utilizzare un simulatore oppure ricorrere a una versione classica dell’elaborazione.
Infine, i criteri di procurement dovrebbero includere, oltre al costo della singola esecuzione:
- l’accesso ai metadati operativi;
- la trasparenza delle code;
- l’esportabilità degli artefatti;
- l’interoperabilità delle API;
- la disponibilità di strumenti open source;
- la trasferibilità delle competenze;
- i costi necessari per abbandonare la piattaforma.
Sovranità quantistica e controllo dell’intero stack
Fin qui il problema è stato considerato dal punto di vista delle organizzazioni che devono portare un workflow quantistico dalla sperimentazione alla messa in esercizio. La stessa questione si pone, su scala più ampia, per i sistemi nazionali della ricerca e dell’innovazione: investire in hardware e progetti sperimentali non basta, se mancano piattaforme, competenze e strumenti operativi per trasformare i risultati scientifici in applicazioni affidabili.
In questa prospettiva, il caso italiano è particolarmente significativo. Il Paese dispone di competenze scientifiche riconosciute e ha sostenuto in misura rilevante la ricerca quantistica attraverso programmi pubblici, ma la sfida è ora consolidare l’infrastruttura tecnica, organizzativa e industriale necessaria per portare questi risultati fuori dal laboratorio. Conta quindi non soltanto la disponibilità di processori, ma anche la possibilità di formare persone, sviluppare piattaforme e far crescere imprese in grado di costruire e gestire l’infrastruttura che li circonda.
Anche la sovranità tecnologica deve essere letta in questa prospettiva. Non può essere misurata soltanto contando le QPU costruite o installate in Italia. Un’infrastruttura potrebbe utilizzare hardware italiano o europeo e rimanere dipendente da compilatori, SDK, servizi cloud, formati proprietari o sistemi di orchestrazione controllati altrove.
La capacità strategica riguarda pertanto l’intero stack: hardware, middleware, piattaforme operative, strumenti di sviluppo, registri degli esperimenti, competenze e comunità software. È in questo spazio che attività apparentemente poco spettacolari, come l’orchestrazione dei workflow, il versionamento degli esperimenti, l’interoperabilità tra provider e la gestione delle risorse ibride, assumono un valore strategico.
La sovranità quantistica non dipenderà soltanto dalla disponibilità di QPU, ma dal controllo dell’intero stack, dalla diffusione delle competenze, dalla possibilità di evitare dipendenze irreversibili e dalla capacità di trasformare i risultati della ricerca in sistemi realmente utilizzabili.
Riferimenti bibliografici
[1] Angelo Impedovo, Miriana Prifti Skenduli, Vito Nicola Losavio, Donato Malerba, Corrado Loglisci, “Operational Validation of Cloud-Native MLOps for Hybrid Quantum–Classical Machine Learning Workflows”, Q-WORKS 1st Workshop on Quantum–HPC Workflows, Resources allocation, and Scheduling, co‑located with Euro‑Par 2026, Pisa, August 24, 2026.
[2] Ronja Heikkinen, Santiago Núñez-Corrales e Vlad Stirbu, “Navigating the Socio-Technical Complexity Challenge in Quantum Software Ecosystems”, preprint, luglio 2026. https://arxiv.org/abs/2607.15135
[3] Poornima Kumaresan, Shwetha Singaravelu, Lakshmi Rajendran e Santhosh Sivasubramani, “Eliminating Vendor Lock-In in Quantum Machine Learning via Framework-Agnostic Neural Networks”, preprint, aprile 2026. https://arxiv.org/abs/2604.04414
Partecipa alla community