Prima di indicare un TRL nel formulario di un bando, vale la pena fermarsi su una domanda: a che livello di maturità è davvero la tecnologia che vogliamo sviluppare? La risposta determina quali prove mancano, quanto lavoro resta da fare e quali risultati sia ragionevole promettere. Un numero scelto soltanto per rispettare un requisito di accesso rischia di nascondere proprio le difficoltà che il progetto dovrebbe affrontare.
I Technology Readiness Levels, in italiano livelli di maturità tecnologica, descrivono il percorso dalle prime osservazioni scientifiche a un sistema dimostrato nell’impiego reale. La scala è utile quando il livello dichiarato è accompagnato da evidenze e riferito a una tecnologia ben identificata. Per collocare questa valutazione nel lavoro complessivo dell’impresa, rimandiamo alla pagina sui progetti di ricerca e sviluppo finanziati e sul nostro accompagnamento.
Che cosa descrivono i nove livelli TRL
La tabella riprende in forma sintetica la scala indicata dalla Commissione europea negli allegati generali di Horizon Europe 2026–2027, pagina 16. Nei programmi che la utilizzano, vanno lette anche le eventuali precisazioni del singolo invito.
| Livello | Stato della tecnologia |
|---|---|
| TRL 1 | Osservati i principi scientifici di base. |
| TRL 2 | Formulata una possibile applicazione tecnologica. |
| TRL 3 | Verificata sperimentalmente la fattibilità del concetto. |
| TRL 4 | Tecnologia validata in laboratorio. |
| TRL 5 | Tecnologia validata in un ambiente rilevante per l’impiego previsto. |
| TRL 6 | Tecnologia dimostrata in un ambiente rilevante. |
| TRL 7 | Prototipo del sistema dimostrato nell’ambiente operativo. |
| TRL 8 | Sistema completato e qualificato. |
| TRL 9 | Sistema effettivo dimostrato nell’impiego operativo. |
Per le tecnologie abilitanti fondamentali, la fonte europea precisa il carattere industrialmente rilevante dell’ambiente ai livelli 5 e 6 e richiama la produzione competitiva al livello 9. La tabella non assegna, da sola, un livello al progetto: per farlo bisogna descrivere quale soluzione è stata provata e in quali condizioni.
TRL iniziale e finale: risultati acquisiti e obiettivi da dimostrare
Il TRL iniziale deve rappresentare ciò che è già sostenuto dalle prove disponibili alla data di riferimento. Un’attività pianificata, anche se il gruppo ritiene probabile che funzioni, non è un risultato acquisito. Il TRL finale descrive invece l’avanzamento atteso e va collegato a verifiche che il progetto si impegna a svolgere.
Per esempio, dichiarare un passaggio dalla validazione in laboratorio alla dimostrazione in un contesto rilevante richiede di spiegare quale differenza esista fra i due ambienti. Quali condizioni saranno riprodotte? Con quali dati e per quanto tempo si proverà la soluzione? Come saranno giudicati i risultati? Queste decisioni devono trovare spazio nel piano delle attività e nel budget.
È utile conservare un dossier delle evidenze: rapporti di prova, versioni del prototipo, dati e criteri di valutazione. Una dimostrazione riuscita ma non documentata è difficile da ricostruire e da far valutare a chi non vi ha assistito.
Laboratorio, ambiente rilevante e ambiente operativo
In laboratorio si lavora in condizioni controllate, utili a isolare i fenomeni e a verificare le prestazioni della tecnologia. Un ambiente rilevante introduce invece le condizioni che possono incidere sul suo funzionamento nell’uso previsto: interferenze, variabilità dei materiali, carichi di lavoro o interazioni con altri sistemi. Può essere un impianto pilota o un ambiente di prova costruito per riprodurre tali condizioni.
L’ambiente operativo è il contesto effettivo di impiego. La distinzione non dipende soltanto dal luogo fisico: installare un prototipo in azienda non basta se viene utilizzato con dati selezionati e procedure estranee al lavoro ordinario. Nella descrizione del progetto conviene precisare quali condizioni sono realistiche e quali restano semplificate.
Che cosa cambia fra TRL 4, 5 e 6
Fra questi livelli cambia anzitutto la qualità della prova rispetto all’impiego previsto. Al TRL 4 la validazione riguarda il laboratorio; al TRL 5 deve essere motivata la rappresentatività dell’ambiente. Al TRL 6 si parla di dimostrazione: diventa essenziale mostrare il funzionamento della tecnologia in quel contesto, con una configurazione e un protocollo sufficientemente definiti.
Nella pratica è utile scrivere in anticipo ciò che distinguerebbe una semplice prova di un componente dalla dimostrazione della soluzione prevista. Il numero dei test, preso isolatamente, non risolve la questione. Cento prove eseguite tutte nella stessa condizione favorevole possono lasciare aperta una difficoltà che si manifesta soltanto nell’interazione con il resto del sistema.
TRL 7, 8 e 9: dal prototipo al sistema in uso
Nei livelli successivi il riferimento si sposta al sistema. La dimostrazione del prototipo in ambiente operativo precede il completamento e la qualificazione della soluzione, fino alla sua comprovata operatività. Per motivare il livello dichiarato, occorre chiarire che cosa sia compreso nel sistema e quali prestazioni siano state verificate.
Questo avanzamento non coincide con la maturità commerciale. Una tecnologia può funzionare stabilmente e avere ancora un prezzo non sostenibile, un canale di vendita da costruire o un servizio di assistenza incompleto. Allo stesso modo, l’interesse manifestato da un potenziale cliente non sostituisce una prova tecnica. Sono valutazioni da tenere entrambe presenti, ma rispondono a domande diverse.
Software e intelligenza artificiale: valutare anche dati e integrazioni
Per un sistema software conviene distinguere ciò che è già stabile da ciò che si sta effettivamente sviluppando. Un’interfaccia funzionante può utilizzare un algoritmo ancora sperimentale; un modello con buoni risultati può dipendere da una preparazione manuale dei dati che non sarebbe sostenibile nell’impiego previsto. Attribuire un unico TRL senza chiarire il perimetro rende poco leggibile questa situazione.
Nei progetti di intelligenza artificiale, le evidenze dovrebbero permettere di capire su quali dati sia stato valutato il modello e quanto questi rappresentino l’uso atteso. Una verifica su dati separati da quelli di addestramento affronta una questione diversa da una prova con nuove fonti, dati incompleti o distribuzioni che cambiano nel tempo. Anche le prestazioni dell’integrazione vanno considerate quando fanno parte della tecnologia che si vuole dimostrare.
Esempio: un sistema AI per il controllo dei difetti
Consideriamo un caso illustrativo, non la descrizione di un progetto cliente. Un’impresa ha provato un modello di visione su fotografie di componenti, raccolte con luce costante e difetti già identificati. Quelle prove possono sostenere una valutazione in laboratorio, se documentano adeguatamente il funzionamento; non dimostrano ancora il comportamento sulla linea.
Il lavoro successivo potrebbe introdurre un banco rappresentativo, con velocità di passaggio e illuminazione variabili, per poi dimostrare l’integrazione fra telecamera, modello e segnalazione dello scarto. In questo percorso diventano utili le misure degli errori nelle diverse condizioni e dei tempi di risposta. Una successiva dimostrazione del prototipo sulla linea in esercizio richiederebbe altre evidenze, comprese quelle sul comportamento durante il normale turno di lavoro. L’attribuzione dei livelli resta da motivare secondo il programma e il perimetro scelti.
Nella Digital Health la prova tecnica non esaurisce le verifiche
Una tecnologia per la salute deve essere valutata rispetto all’uso e agli utenti previsti. Per stimare il TRL occorre capire quali aspetti siano già stati verificati e quali dipendano ancora da condizioni controllate. La maturità tecnologica, però, non dimostra automaticamente l’utilità clinica e non sostituisce gli adempimenti applicabili alla soluzione. Il piano deve distinguere questi percorsi, coordinandone i tempi.
Esempio: misurare il movimento durante la riabilitazione
Immaginiamo un sistema che ricavi misure del movimento da sensori indossabili. Una prima verifica potrebbe confrontare le misure con un riferimento in laboratorio. Per avvicinarsi a un ambiente rilevante, il gruppo dovrebbe valutare anche il posizionamento dei sensori e la variabilità dei movimenti in condizioni rappresentative dell’uso previsto.
La dimostrazione del prototipo durante l’attività della struttura sanitaria aggiungerebbe questioni diverse: configurazione da parte degli operatori, continuità delle acquisizioni e integrazione nel flusso di lavoro. In ciascun passaggio servono protocolli e risultati coerenti con ciò che si dichiara di aver dimostrato. Anche questo è un esempio metodologico: il livello effettivo dipende dalle prove e non può essere dedotto dal solo fatto che il sistema sia stato portato in una struttura sanitaria.
Come leggere insieme TRL, ricerca industriale e sviluppo sperimentale
Il TRL descrive la maturità di una tecnologia; ricerca industriale e sviluppo sperimentale descrivono la natura delle attività. Le due valutazioni si incontrano nella progettazione, ma non esiste una corrispondenza automatica e universale fra specifici TRL e queste categorie. Un prototipo può servire ad acquisire conoscenze nuove oppure a validare una soluzione costruita su conoscenze disponibili.
Per classificare il lavoro occorre quindi esaminarne gli obiettivi e l’incertezza da affrontare, come spieghiamo nella guida alla distinzione tra ricerca industriale e sviluppo sperimentale. Se un programma stabilisce un proprio rapporto fra categorie e livelli, quella regola va applicata nel suo ambito, senza estenderla a ogni progetto R&S.
Come stimare il TRL di un progetto
Il primo passo è identificare la tecnologia che si sta valutando, con la sua versione e l’impiego previsto. In un sistema composto da più tecnologie può essere necessario descrivere livelli diversi e chiarire come lo stato delle integrazioni condizioni quello dell’insieme.
Si esaminano poi i risultati disponibili: che cosa è stato provato, in quale ambiente e con quali limiti. Rapporti e dati permettono di distinguere le prestazioni dimostrate dalle ipotesi ancora aperte. Su questa base si può motivare il livello iniziale, rendendo espliciti gli eventuali punti che richiedono approfondimento.
Per definire il livello finale si procede dal risultato atteso alle prove necessarie a sostenerlo. Il piano dovrebbe precisare chi predisporrà l’ambiente di test, quali criteri saranno utilizzati e quali documenti resteranno a disposizione al termine. Prima di chiudere la valutazione, è utile controllare che:
- tecnologia, configurazione e uso previsto siano descritti senza ambiguità;
- ogni risultato dichiarato sia collegato a una prova e al relativo ambiente;
- i limiti delle evidenze iniziali siano visibili;
- le verifiche finali abbiano responsabili, tempi e risorse nel piano.
Gli errori che rendono poco credibile il livello dichiarato
Scegliere il TRL richiesto dal bando e cercare dopo una giustificazione capovolge la valutazione. Se manca una prova essenziale, è più utile riconoscere il lavoro ancora necessario e verificare se lo strumento sia adatto. L’esistenza di un prototipo non autorizza, da sola, un livello elevato: bisogna sapere che cosa faccia e in quali condizioni abbia funzionato.
Un altro errore consiste nell’attribuire lo stesso livello a tutti i componenti, ignorando quello meno maturo o la mancanza di prove sull’integrazione. Infine, né l’interesse del mercato né l’intenzione di arrivare a una certa maturità costituiscono evidenze tecniche. Un TRL finale senza verifiche programmate resta un obiettivo non dimostrabile.
Quando questa ricostruzione è chiara, diventa più semplice valutare i finanziamenti coerenti con il progetto. Per approfondire anche la definizione delle attività, del partenariato e della gestione, puoi leggere la guida generale ai progetti R&S finanziati.