Autore: Luca Mozzillo

  • Sotto la superficie: innovazione e dimensione subacquea

    QUADERNO / ECOSISTEMI E PROSPETTIVE

    Il mare non è soltanto uno spazio da attraversare. È anche un ambiente nel quale infrastrutture, conoscenza scientifica e tecnologie devono convivere in condizioni complesse.

    Un post di Monica Albini, che ho commentato su LinkedIn, richiama il rapporto tra mare, connettività, energia e infrastrutture. È uno spunto per guardare alla dimensione subacquea dal punto di vista della ricerca: non come una singola specializzazione, ma come un incontro tra discipline.

    L’agenda pubblica del Polo Nazionale della dimensione Subacquea rende visibile questa varietà. Tra i temi dei bandi figurano navigazione, cavi per il monitoraggio marino, reti e soluzioni energetiche. Non ne ricavo una classifica delle tecnologie più importanti; mi interessa il fatto che nessuna possa essere considerata completamente isolata dalle altre.

    Pensare alle relazioni tra componenti

    Immaginiamo, in termini generali, un sistema dedicato all’osservazione ambientale. Un sensore produce un’informazione, ma per renderla utilizzabile servono energia, acquisizione dei dati, trasmissione, interpretazione e una modalità per verificare ciò che viene osservato.

    La prestazione di un componente non descrive da sola quella dell’intero sistema. Per questo partirei dalle relazioni: quali informazioni devono passare tra i diversi elementi, quali condizioni sono state ipotizzate e quali dipendenze richiedono una prova comune? È un modo per rendere il confronto multidisciplinare più concreto.

    Collegare modellazione e osservazione

    Una simulazione può aiutare a strutturare le ipotesi, mentre una prova permette di confrontarle con osservazioni. Nel definire un percorso di ricerca terrei distinti questi contributi: che cosa il modello rappresenta, quali dati lo sostengono e quali condizioni non sono ancora state verificate.

    Proporrei passi progressivi, con obiettivi chiari per ciascuna verifica. Non per trasformare una prova iniziale in una promessa di funzionamento universale, ma per capire in modo ordinato quali domande sono state affrontate e quali restano aperte.

    Anche il dato ha bisogno di contesto

    Raccogliere un’informazione non equivale a comprenderla. In una collaborazione, chiederei che i dati siano accompagnati dalle condizioni di acquisizione, dalle incertezze note e dalle regole per il loro utilizzo. Senza questo contesto, anche un archivio ricco può risultare difficile da interpretare.

    Per i contenuti che riguardano infrastrutture, considererei inoltre con attenzione che cosa possa essere condiviso pubblicamente. Fare divulgazione non richiede di esporre dettagli operativi sensibili: si possono raccontare sfide, metodi e opportunità mantenendo un livello appropriato di generalità.

    Un terreno comune per competenze diverse

    È questo l’aspetto della dimensione subacquea che trovo particolarmente interessante: costringe a collegare materiali, strumenti di misura, energia e analisi dei dati. L’innovazione non coincide con la somma delle singole capacità, ma con il lavoro necessario per renderle compatibili.

    Per raccontarla partirei dunque da una domanda semplice: quale conoscenza o capacità manca e chi può contribuire a costruirla? Sotto la superficie c’è anche questo, un’occasione per imparare a progettare insieme.


    Origine dello spunto. Il mare come infrastruttura. Il post di Monica Albini. Approfondimento: Marina Militare — Bandi PNS.

    ← Torna al Quaderno di ricerca

  • Dual use: una parola utile, se la prendiamo sul serio

    QUADERNO / ECOSISTEMI E PROSPETTIVE

    Definire una tecnologia dual use non dovrebbe essere un modo per renderla più interessante sulla carta. Dovrebbe aprire una discussione più precisa sul contesto in cui sarà utilizzata.

    Il tema compare spesso nei confronti tra industria, ricerca e istituzioni, compresi quelli condivisi nella mia attività LinkedIn. La Commissione europea usa il termine per beni, software e tecnologie che possono avere impieghi sia civili sia militari. È una definizione utile, ma non esaurisce le domande che interessano chi progetta o gestisce innovazione.

    La possibilità non è ancora trasferibilità

    Una base tecnologica può essere comune, mentre le condizioni d’impiego sono differenti. Per questo eviterei di presentare il trasferimento da un settore a un altro come un semplice cambio di destinatario. Occorre capire quali ipotesi restano valide e quali richiedano nuove verifiche.

    Consideriamo, in termini generali, uno strumento di simulazione o di analisi dei dati. Prima di riutilizzarlo in un nuovo contesto chiederei quali decisioni dovrà supportare, quali informazioni potrà utilizzare e chi valuterà il risultato. Lo stesso software può entrare in processi molto diversi senza che la sua precedente validazione copra automaticamente il nuovo impiego.

    Rendere visibili requisiti e limiti

    Il lavoro tecnico dovrebbe rendere riconoscibile il confine della soluzione: che cosa è stato provato, con quali dati e per quale scopo. Un requisito non è soltanto un vincolo da soddisfare; è anche il modo in cui un’organizzazione chiarisce ciò che considera accettabile.

    Proporrei quindi di documentare il contesto d’uso insieme alle prestazioni. Questa informazione aiuta sia chi sviluppa sia chi acquisisce una tecnologia a evitare interpretazioni eccessive. Una capacità dimostrata in un ambiente delimitato non diventa universale perché cambia il linguaggio della presentazione.

    La responsabilità non arriva alla fine

    Le possibili destinazioni di una tecnologia meritano attenzione fin dalle prime scelte. Nella mia prospettiva, il confronto dovrebbe includere competenze tecniche, organizzative e di conformità, oltre alla valutazione delle conseguenze prevedibili. Non è un passaggio da ridurre a una dichiarazione standard.

    Il quadro europeo prevede controlli per determinate attività relative ai prodotti a duplice uso. Le valutazioni sui singoli prodotti richiedono competenze tecniche e di conformità, con attenzione al caso specifico. Potenzialità e responsabilità vanno considerate insieme.

    Un lessico più preciso aiuta il confronto

    Al posto di dire soltanto “è dual use”, proverei a completare la frase: quale capacità è condivisa, quali condizioni cambiano e quali verifiche mancano? Questa formulazione trasforma un’etichetta in una discussione di lavoro.

    La ricerca può aprire applicazioni inattese. Affrontarle con rigore non significa ridurre l’ambizione, ma darle una base più solida. Una tecnologia interessante è quella di cui sappiamo discutere anche limiti, responsabilità e condizioni di utilizzo, non soltanto opportunità.


    Origine dello spunto. Panel Aerospace & Defence, Convention 25 anni Mare Group, Salerno, 24 luglio 2026. L’evento. Approfondimento: Commissione europea — Prodotti a duplice uso.

    ← Torna al Quaderno di ricerca

  • Il quantistico: meno mito, più metodo

    QUADERNO / TECNOLOGIA E LAVORO

    Il calcolo quantistico merita curiosità, ma non ha bisogno di promesse assolute. La domanda utile è dove abbia senso metterlo alla prova e con quali criteri valutarne il contributo.

    In un post LinkedIn ho condiviso l’interesse per il calcolo ibrido e per le sue possibili applicazioni alla simulazione. Da quello spunto nasce questa riflessione: come avvicinarsi a una tecnologia emergente senza confondere la possibilità di sperimentare con un vantaggio già dimostrato?

    La distinzione è importante. Esistenza dell’hardware, disponibilità di strumenti di sviluppo e utilità per uno specifico problema sono questioni differenti. Nessuna delle prime due, da sola, risolve automaticamente la terza.

    Che cosa significa lavorare in modo ibrido

    La documentazione didattica IBM descrive gli algoritmi variazionali come un’interazione tra calcolo classico e quantistico: un circuito parametrizzato viene eseguito, i risultati sono valutati e una procedura classica aggiorna i parametri. È un esempio concreto di complementarità, non di sostituzione integrale dei computer tradizionali.

    Questo schema aiuta a cambiare prospettiva. Non chiederei quale applicazione possa ricevere l’etichetta “quantistica”, ma quale parte del problema giustifichi una prova con questi strumenti. Il resto del processo continua a contare: preparazione dei dati, integrazione, interpretazione e verifica.

    Scegliere un confronto credibile

    Immaginiamo un problema di ottimizzazione. Prima di impostare l’esperimento definirei un metodo classico di riferimento, un insieme di casi e una misura del risultato. Confrontare una proposta nuova con una soluzione volutamente debole non aiuterebbe a capire il suo valore.

    Considererei inoltre il processo completo, non soltanto il tempo di una singola esecuzione. Quanta preparazione serve? Quante ripetizioni? Quanto costa verificare il risultato? Quali ipotesi sono state introdotte per rendere il problema trattabile? Sono domande che rendono la sperimentazione più istruttiva, anche quando l’esito non è favorevole.

    Dire chiaramente che cosa è stato provato

    Un circuito eseguito su un simulatore classico e uno eseguito su hardware quantistico non sono la stessa evidenza. Allo stesso modo, risolvere un caso piccolo non dimostra come si comporterà il metodo su istanze industriali. Nel raccontare il lavoro distinguerei sempre ambiente, dimensione del problema e limiti del test.

    La stessa prudenza vale per il termine “vantaggio”. Per usarlo occorre indicare rispetto a quale riferimento, su quale metrica e in quali condizioni. Un risultato promettente può essere importante senza essere presentato come una superiorità generale.

    Costruire capacità di valutazione

    Nel frattempo, l’obiettivo può essere imparare a formulare problemi, riconoscere ipotesi e dialogare con gli specialisti. Non ogni organizzazione deve sviluppare tutte le competenze al proprio interno, ma dovrebbe poter comprendere ciò che viene proposto e quali evidenze mancano.

    È questo il metodo con cui affronterei il quantistico: una domanda circoscritta, un confronto serio e risultati raccontati con precisione. Meno fretta di annunciare una svolta, più attenzione a costruire conoscenza utilizzabile.


    Origine dello spunto. Calcolo ibrido e simulazione. Il mio post su LinkedIn. Approfondimento: IBM Quantum — Algoritmi variazionali.

    ← Torna al Quaderno di ricerca

  • Il fattore umano non è il contrario della tecnologia

    Il fattore umano non è il contrario della tecnologia

    QUADERNO / TECNOLOGIA E LAVORO

    Mettere una persona a confermare l’output di un sistema non basta a rendere il processo responsabile. Occorre darle informazioni, tempo e possibilità reali di intervenire.

    Il confronto sul fattore umano nello sviluppo aumentato apre una questione organizzativa, oltre che tecnologica. In un altro articolo del Quaderno ho proposto di chiedersi quali capacità vogliamo aumentare. Qui vorrei guardare più da vicino a ciò che accade quando uno strumento entra nel lavoro quotidiano.

    La domanda non è se lasciare spazio alle persone oppure all’automazione. È come distribuire compiti e responsabilità senza creare una supervisione soltanto apparente. Il punto di partenza che proporrei è il lavoro reale, comprese le sue interruzioni, le informazioni mancanti e le condizioni meno frequenti.

    Confermare non equivale a controllare

    Immaginiamo una procedura che presenti all’operatore una raccomandazione e due pulsanti: accetta o rifiuta. Prima di considerarla una forma di controllo umano, chiederei quali elementi permettano di scegliere. Sono visibili i dati rilevanti? Si può chiedere una verifica? Il rifiuto viene registrato come un errore o come un’informazione da capire?

    La responsabilità dovrebbe corrispondere a una capacità effettiva di azione. Una persona non può essere trattata come garante di un risultato se non dispone degli strumenti per comprenderlo o contestarlo. Questo principio merita attenzione già nella progettazione dell’interfaccia e del processo.

    Preparare i casi che non rientrano nella routine

    Per la formazione non sceglierei soltanto esempi perfettamente riusciti. Includerei casi incompleti, risposte incoerenti e situazioni nelle quali occorre fermarsi. Non per generare sfiducia nello strumento, ma per costruire un’aspettativa proporzionata alle sue capacità.

    Chiarirei inoltre il percorso di segnalazione: chi prende in carico un dubbio, come si conserva il contesto e quando serve coinvolgere una competenza diversa. Una procedura di escalation comprensibile può essere più utile di un’avvertenza generica sul dovere di controllare tutto.

    Osservare il sistema nel tempo

    Il NIST AI RMF Playbook organizza le azioni di gestione del rischio intorno a governance, comprensione del contesto, misurazione e gestione. È un riferimento utile per ricordare che la valutazione non si esaurisce al momento dell’introduzione di una tecnologia.

    In una sperimentazione raccoglierei anche i casi in cui le persone hanno corretto una proposta, chiesto aiuto o scelto di non usare il sistema. Queste osservazioni possono indicare un problema nei dati, nell’interfaccia oppure nella distribuzione dei compiti. Il loro valore sta nella possibilità di migliorare il processo, non di cercare un colpevole.

    Il fattore umano, così inteso, non è un residuo da proteggere contro il progresso. È parte delle condizioni che rendono una tecnologia utilizzabile. Automazione e competenze crescono insieme quando le persone possono capire che cosa sta accadendo, riconoscere i limiti e contribuire a correggerli.


    Origine dello spunto. Panel Industry & Transportation, Convention 25 anni Mare Group, Salerno, 24 luglio 2026. L’evento. Approfondimento: NIST — AI RMF Playbook.

    Foto illustrativa: ThisisEngineering / Unsplash · Licenza.

    ← Torna al Quaderno di ricerca

  • Ricerca europea, senza retorica

    QUADERNO / ECOSISTEMI E PROSPETTIVE

    Fare rete non è ancora collaborare. La differenza si vede quando un incontro cambia il modo in cui si definisce un problema e si organizza il lavoro necessario per affrontarlo.

    Nei racconti degli incontri europei è naturale valorizzare le persone conosciute e le tecnologie presentate. Il passo successivo mi sembra altrettanto importante: capire che cosa rende quel confronto utile una volta tornati alle attività quotidiane.

    Gli incontri EDF ed EDA a Bruxelles nel 2024 mi hanno lasciato una domanda: quali condizioni permettono a competenze diverse di lavorare davvero su un obiettivo comune?

    Una domanda comune vale più di una formula comune

    Un partenariato può riconoscersi nello stesso titolo e attribuirgli significati differenti. Per qualcuno l’interesse principale è un metodo scientifico, per altri un’applicazione, per altri ancora una capacità produttiva. Rendere esplicite queste differenze è il primo lavoro da fare, non un problema da rimandare.

    Proporrei di descrivere insieme la decisione che si vuole supportare o il limite che si vuole superare. La formulazione dovrebbe essere abbastanza precisa da orientare una prova, ma aperta al contributo di discipline differenti. Un obiettivo ambiguo consente accordi rapidi; uno comprensibile consente lavoro condiviso.

    Dare un significato operativo ai contributi

    Non basta dire che un partner porta esperienza. Occorre capire quali dati, strumenti, verifiche o decisioni rende possibili. Lo stesso vale per le interfacce: chi consegna che cosa, in quale forma, a chi lo utilizzerà?

    Immaginiamo due gruppi che sviluppino parti dello stesso dimostratore. Una riunione dedicata ai criteri di prova può essere più utile di una lunga successione di aggiornamenti separati. Permette di scoprire presto se i risultati saranno confrontabili e quali ipotesi devono essere allineate.

    La collaborazione richiede confini chiari

    Condividere non significa trasferire ogni informazione. Significa stabilire quali contenuti possono circolare, con quali responsabilità e per quale scopo. Quando questi confini sono comprensibili, il confronto può essere più concreto e meno condizionato da aspettative implicite.

    Terrei inoltre traccia delle decisioni e dei dubbi irrisolti. In una rete internazionale non tutti partecipano agli stessi scambi: un documento breve, leggibile anche fuori dalla riunione, aiuta a mantenere continuità senza moltiplicare le call.

    Che cosa rimane?

    Il criterio che userei per valutare una collaborazione è anche questo: quali capacità restano alle organizzazioni? Un metodo appreso, una prova ripetibile, una relazione affidabile o un linguaggio condiviso possono continuare a essere utili oltre il perimetro iniziale.

    Raccontare la ricerca europea senza retorica significa darle concretezza. Meno enfasi sul fatto di essere insieme e più attenzione al lavoro che insieme diventa possibile. La dimensione internazionale acquista valore quando rende migliori le domande, le verifiche e le scelte.


    Origine dello spunto. Incontri EDF ed EDA, Bruxelles, 2024. EDF Info Days, 28–29 maggio 2024 — Commissione europea.

    ← Torna al Quaderno di ricerca

  • Perché le visite tecniche contano ancora

    QUADERNO / PERSONE E ORGANIZZAZIONI

    Una visita tecnica è utile quando ci fa tornare con domande migliori. Non soltanto con fotografie di un impianto o con il nome di un nuovo strumento.

    Una presentazione descrive una capacità. Entrare in un laboratorio permette di osservare il contesto che la rende possibile: preparazione dei campioni, attrezzature, tempi e scelte operative. Per questo terrei le visite tra gli strumenti di lavoro, senza considerarle automaticamente un’alternativa a call e documenti.

    Il confronto con realtà come Fraunhofer IKTS offre uno spunto concreto. Il laboratorio NDT dell’istituto impiega metodi non distruttivi su materiali metallici, ceramici e compositi: competenze diverse che invitano a guardare insieme il materiale, la misura e il problema industriale.

    Preparare la domanda prima del viaggio

    Prima di partire sceglierei un problema preciso. Non “vedere che cosa fanno”, ma comprendere se una certa capacità possa rispondere a un’esigenza: rilevare un difetto, caratterizzare un materiale o verificare un’ipotesi di processo.

    Porterei le informazioni condivisibili: caratteristiche del caso, condizioni d’uso e vincoli. Senza dati di contesto, anche la risposta di uno specialista rischia di restare generica. Allo stesso tempo, chiarirei in anticipo che cosa non può essere fotografato o trasferito fuori dal laboratorio.

    Guardare anche ciò che precede la misura

    Durante la visita chiederei di seguire il percorso di un campione o di una prova. Come viene preparato? Quali condizioni devono essere rispettate? Che cosa cambia tra un caso ideale e uno industriale? Queste domande aiutano a capire il lavoro necessario dietro al risultato finale.

    Immaginiamo un metodo capace di rilevare una discontinuità in un provino. La domanda successiva riguarda il componente reale: accessibilità, geometria, variabilità e tempo disponibile. Non significa mettere in dubbio la prova; significa comprendere quanto del contesto sperimentale possa essere trasferito.

    Restituire il confronto

    Al rientro preparerei una nota breve con tre parti: ciò che abbiamo osservato, ciò che ipotizziamo e ciò che va ancora verificato. Separarle impedisce che un’impressione positiva diventi, senza passaggi intermedi, una promessa di fattibilità.

    La nota dovrebbe arrivare anche alle persone che non hanno partecipato. Un confronto utile non resta patrimonio di chi viaggia: dovrebbe rendere più informato il lavoro del gruppo e indicare il passo successivo, per esempio una prova preliminare o uno scambio di specifiche.

    La visita tecnica vale dunque per il collegamento che costruisce tra conoscenza dichiarata e condizioni reali. Il risultato non è poter dire “ci siamo stati”, ma capire meglio che cosa potremmo fare insieme e che cosa ancora non sappiamo.


    Origine dello spunto. Il confronto con i laboratori di ricerca e le prove non distruttive. Fraunhofer IKTS — NDT Test Lab.

    ← Torna al Quaderno di ricerca

  • Il valore delle competenze ibride

    Il valore delle competenze ibride

    QUADERNO / PERSONE E ORGANIZZAZIONI

    Una competenza ibrida non consiste nel sapere un po’ di tutto. Consiste nel possedere una base solida e saper costruire un dialogo con chi guarda lo stesso problema da un’altra prospettiva.

    Nei confronti tra industria e ricerca, la difficoltà non è sempre trovare persone competenti. Può essere capire come far incontrare conoscenze che usano linguaggi, criteri e tempi diversi. Per me, è proprio qui che le competenze tecniche incontrano la capacità di ascoltare e collaborare.

    Tradurre senza impoverire

    Immaginiamo una discussione tra un progettista, uno sviluppatore e un responsabile di produzione. La stessa parola, “pronto”, può indicare un modello completato, una funzione implementata o un processo utilizzabile. Nessuno dei tre sta necessariamente sbagliando: stanno parlando di soglie differenti.

    Chi collega questi mondi non deve sostituirsi agli specialisti. Deve aiutare il gruppo a precisare le condizioni: pronto per quale prova, con quali limiti e sotto la responsabilità di chi? È un’attività concreta, che trasforma una parola generica in un accordo verificabile.

    Profondità prima dell’ampiezza

    Non considero la versatilità un’alternativa al rigore. Una preparazione approfondita aiuta a riconoscere che cosa si sa e che cosa richiede un’altra competenza. La curiosità verso altri ambiti diventa utile quando non nasconde questo confine.

    In una riunione, una buona traduzione potrebbe essere: “Ho capito l’obiettivo, ma per valutare questa ipotesi ci serve il contributo di chi segue le prove”. Chiedere aiuto non indebolisce il ruolo. Può rendere più affidabile la decisione e più visibile il contributo degli altri.

    Allenare le interfacce tra persone

    Per sviluppare queste capacità proporrei attività condivise su problemi circoscritti. Non soltanto corsi separati, ma occasioni in cui due discipline producano insieme una scelta, un criterio di prova o una breve descrizione delle ipotesi adottate.

    Un esercizio utile è chiedere a ciascuno di spiegare la propria esigenza senza dare per scontati i termini del mestiere. Un secondo è far restituire all’interlocutore ciò che ha compreso. La differenza tra le due versioni spesso indica dove lavorare, prima ancora della soluzione tecnica.

    Non creare un nuovo collo di bottiglia

    Esiste anche un rischio: affidare ogni collegamento alla stessa persona. Una figura capace di mediare è preziosa, ma non dovrebbe diventare l’unico passaggio possibile. L’obiettivo dovrebbe essere rendere il gruppo progressivamente più capace di dialogare senza dipendere sempre da un interprete.

    Per questo darei valore ai documenti brevi, alle decisioni tracciate e alle domande rese esplicite. Le competenze ibride funzionano quando lasciano una capacità condivisa, non soltanto quando risolvono bene un singolo incontro. Il loro risultato migliore è un’organizzazione che impara a capirsi.


    Origine dello spunto. Persone e competenze alla Convention 25 anni Mare Group, Salerno, 24 luglio 2026. L’evento.

    Foto illustrativa: Headway / Unsplash · Licenza.

    ← Torna al Quaderno di ricerca

  • L’AI ha senso solo se migliora le decisioni

    QUADERNO / TECNOLOGIA E LAVORO

    Nel supporto alle decisioni industriali, il punto non è introdurre un algoritmo. È capire quale scelta debba diventare più informata e che cosa occorra per verificarlo.

    Parlando di machine learning per la produzione ho richiamato il legame tra previsioni e gestione operativa. Qui vorrei isolare la domanda che viene prima di qualsiasi progetto: che cosa cambierebbe nel lavoro se quella previsione fosse disponibile?

    Una dashboard può mostrare una probabilità o segnalare un’anomalia. Se però non è chiaro chi deve valutarla, quali alternative possiede e quando intervenire, l’informazione resta separata dalla decisione. Per me è questa distanza che un sistema di supporto dovrebbe aiutare a ridurre.

    Definire l’azione prima della metrica

    Immaginiamo una previsione di indisponibilità di una macchina. Il responsabile può anticipare un controllo, modificare la sequenza produttiva oppure continuare a osservare. Le conseguenze di queste scelte sono diverse: una previsione non andrebbe giudicata senza considerare le azioni che rende possibili.

    Chiederei quindi di descrivere un caso concreto, anche su una sola pagina: segnale disponibile, decisione da prendere, tempo utile e conseguenza dell’errore. Questo documento renderebbe più chiaro anche quali dati raccogliere e quali prestazioni misurare.

    Confrontare con il lavoro che si fa già

    Il confronto non dovrebbe essere tra un sistema intelligente e il nulla. Esiste quasi sempre un metodo di riferimento: una regola, un controllo manuale, una pianificazione, l’esperienza di un operatore. La nuova soluzione va confrontata con quel punto di partenza in condizioni dichiarate.

    Un risultato medio può inoltre nascondere casi difficili. Per questo distinguerei situazioni abituali, condizioni poco rappresentate nei dati e scenari nei quali il sistema dovrebbe segnalare incertezza. Rinunciare a fornire una risposta può essere più utile che proporre una precisione apparente.

    Anche l’utilizzo deve essere osservato

    Il NIST propone di guardare all’interazione tra persone e AI a partire da obiettivi e risultati, non soltanto dalla tecnica impiegata. Questa prospettiva aiuta a porre una domanda pratica: l’informazione arriva nella forma e nel momento in cui può essere utilizzata?

    Nella prova includerei le persone che prenderanno la decisione. Verificherei se comprendono il segnale, se riescono a contestarlo e se possono documentare il motivo di un intervento. Non per trasferire su di loro ogni problema del sistema, ma per progettare una responsabilità realistica.

    Il valore va dimostrato, non annunciato

    Una sperimentazione ben impostata potrebbe concludere che l’AI serve soltanto in una parte del processo, o che prima occorre migliorare i dati. Non lo considererei un fallimento. È un risultato utile, perché evita di adottare una soluzione prima di aver chiarito il problema.

    Nel supporto decisionale, misurerei ciò che cambia nella scelta e nel lavoro, senza fermarmi alla qualità apparente della previsione. È lì che cercherei il valore dell’AI.


    Origine dello spunto. Machine learning e decisioni nella produzione industriale. Il mio post su LinkedIn. Approfondimento: NIST — AI Use Taxonomy.

    ← Torna al Quaderno di ricerca

  • XR: quando smette di essere una demo

    QUADERNO / TECNOLOGIA E LAVORO

    Una scena immersiva può sorprendere in pochi secondi. Per diventare uno strumento di lavoro deve rispondere a una domanda più esigente: che cosa permette di fare meglio?

    In un commento a un workshop sui Digital Twin ho raccontato il nostro interesse per scenari tridimensionali rapidi da costruire, interattivi e utilizzabili per simulazione e addestramento. È un punto da cui partire per una riflessione più generale: il valore non sta soltanto nel rappresentare un ambiente, ma nel rendere possibile un’attività al suo interno.

    Dal contenitore all’obiettivo

    Prima di scegliere un visore, chiederei quale problema si vuole affrontare. Comprendere una geometria? Ripetere una sequenza? Esercitarsi in uno scenario difficile da riprodurre? Ogni risposta richiede un’esperienza diversa. Usare la stessa soluzione per tutte queste esigenze rischia di trasformare l’XR in un contenitore senza un compito chiaro.

    Immaginiamo un’attività di formazione su un componente. Non basta poterlo ruotare e ingrandire. Bisogna decidere che cosa osservare, quali errori riconoscere e come capire se la persona abbia acquisito una competenza trasferibile al contesto reale.

    Il realismo utile è selettivo

    In questo esempio potrei preferire una grafica meno dettagliata ma istruzioni più leggibili. Per un compito diverso potrebbe essere essenziale una rappresentazione accurata delle distanze o delle occlusioni. La fedeltà dovrebbe seguire la decisione da supportare, non una ricerca indistinta dell’effetto cinematografico.

    Allo stesso modo, chiederei di separare le informazioni certe da quelle ricostruite. Un ambiente digitale può apparire completo anche quando alcuni dati non lo sono. Rendere visibile questa differenza aiuta a non attribuire al modello più affidabilità di quella che possiede.

    L’esperienza va mantenuta, non soltanto creata

    Il passaggio alla pratica introduce una domanda meno spettacolare: chi aggiorna i contenuti? Se cambia il componente o la procedura, l’esperienza deve poter cambiare con essi. Nella valutazione includerei quindi origine dei modelli, revisioni, responsabilità di approvazione e tempo necessario per una modifica.

    Considererei anche l’accessibilità dell’attività: alternative al visore, durata delle sessioni, leggibilità, possibilità di interrompere e riprendere. Non tutte le persone e non tutti i contesti possono adottare lo stesso dispositivo nelle stesse condizioni.

    Una prova di utilità, non una promessa

    Per verificare il valore proporrei una prova circoscritta: lo stesso compito, criteri dichiarati prima, osservazioni sugli errori e un confronto con il metodo abituale. L’obiettivo non sarebbe dimostrare a ogni costo che l’XR è migliore, ma capire dove aggiunge qualcosa e dove no.

    È in quel momento che smette di essere una demo: quando possiamo discutere di comprensione, manutenzione dei contenuti e qualità del lavoro, oltre che dell’impressione iniziale. Il miglior risultato potrebbe anche essere una soluzione ibrida, in cui l’immersione serve solo nei passaggi che la richiedono davvero.


    Origine dello spunto. Workshop EDA sui Digital Twin: scenari immersivi per simulazione e addestramento. La discussione su LinkedIn.

    ← Torna al Quaderno di ricerca

  • Dall’hackathon al lavoro utile

    Dall’hackathon al lavoro utile

    QUADERNO / TECNOLOGIA E LAVORO

    Un prototipo costruito in un fine settimana non è ancora un prodotto. Può però essere un ottimo modo per capire quale domanda meriti il lavoro dei mesi successivi.

    Di un hackathon è facile ricordare il ritmo: un problema da affrontare, persone che si conoscono in fretta, una consegna ravvicinata. A me interessa soprattutto ciò che questa concentrazione rende visibile: le ipotesi del gruppo, le scelte di priorità e la capacità di rinunciare a una funzione per dimostrarne bene un’altra.

    La challenge Mare Group di The Big Hack 2025 proponeva un problema concreto: portare modelli CAD dentro ambienti immersivi per formazione e progettazione. Una sfida che chiedeva di andare oltre l’effetto visivo e mettere alla prova un possibile utilizzo industriale.

    Prima il problema, poi l’effetto sorpresa

    Immaginiamo un team che debba rendere interattivo un modello tridimensionale. Una scena spettacolare può attirare l’attenzione, ma non risponde necessariamente alla domanda principale: quanto lavoro occorre per importare un nuovo componente e trasformarlo in un’istruzione utile?

    Per impostare la prova partirei da un caso d’uso piccolo e rappresentativo. Chi userà la soluzione? Quale passaggio oggi è lento o ambiguo? Quale risultato potrà osservare la giuria? Sono domande che aiutano a distinguere una dimostrazione di abilità da una verifica del valore proposto.

    Una demo dovrebbe mostrare anche i limiti

    Presentare solo ciò che funziona rende difficile valutare la maturità dell’idea. Preferirei vedere anche il confine: quali file sono supportati, quali passaggi sono manuali, che cosa accade quando il modello contiene dati incompleti. Un limite dichiarato bene è un’informazione utile, non un difetto da nascondere.

    Il team può tenere un breve diario delle decisioni: abbiamo scelto questo formato, escluso questa funzione, provato questo percorso. Alla fine, quel diario racconta il ragionamento dietro il prototipo e permette a un altro gruppo di ripartire senza dover ricostruire tutto da zero.

    Il passaggio decisivo arriva dopo

    Per me, il seguito non dovrebbe essere un generico invito a continuare. Servono una persona responsabile, una prova successiva e un criterio per decidere se investire ancora. Potrebbe bastare testare la soluzione con un utilizzatore reale, su un modello diverso da quello preparato per la presentazione.

    È lì che distinguerei tre risultati: ciò che è stato dimostrato, ciò che appare promettente e ciò che non è ancora stato verificato. Questa separazione protegge il valore del lavoro e impedisce di confondere entusiasmo e affidabilità.

    Un buon hackathon, allora, non deve fingere di completare l’innovazione. Deve lasciare un problema meglio definito, una prima evidenza e persone capaci di proseguire insieme. Anche una soluzione che non viene adottata può aver fatto emergere una domanda importante.


    Origine dello spunto. The Big Hack 2025, Napoli: la challenge Mare Group su CAD e ambienti immersivi. Programma e challenge.

    Foto illustrativa: Headway / Unsplash · Licenza.

    ← Torna al Quaderno di ricerca