Un impianto farmaceutico può rimanere in servizio per venti o trent’anni. Un sistema operativo, un software industriale o un componente di automazione seguono invece cicli tecnologici molto più brevi. È proprio questa differenza a creare uno dei problemi meno visibili della trasformazione digitale del manufacturing.
Una linea può continuare a produrre in modo affidabile e un’apparecchiatura può essere perfettamente efficiente dal punto di vista meccanico, mentre il sistema digitale che ne governa alcune funzioni è già entrato in una fase di obsolescenza. Il produttore potrebbe avere interrotto il supporto di un software, un componente hardware potrebbe essere difficile da reperire oppure una determinata versione del sistema operativo potrebbe non ricevere più aggiornamenti di sicurezza.
In un normale ambiente informatico, la risposta potrebbe sembrare semplice: aggiornare o sostituire. Nel farmaceutico la questione è più complessa, perché la tecnologia è inserita all’interno di processi qualificati e sistemi computerizzati validati. Ogni modifica deve quindi essere valutata rispetto al suo impatto sul processo, sul prodotto, sui dati e sullo stato di controllo.
Il risultato è un paradosso industriale: un sistema può continuare a funzionare correttamente e, nello stesso tempo, diventare progressivamente più difficile da mantenere in condizioni accettabili di sicurezza e compliance.
Legacy non significa necessariamente inadeguato
Il termine legacy viene spesso utilizzato con una connotazione negativa. In realtà, l’età di una tecnologia non è sufficiente per determinarne l’adeguatezza.
Un sistema installato molti anni fa può continuare a svolgere perfettamente la funzione per la quale è stato progettato. Può essere stabile, conosciuto dagli operatori e supportato da una lunga esperienza produttiva. Sostituirlo soltanto perché esiste una tecnologia più recente non rappresenta necessariamente una buona decisione industriale.
La questione cambia quando l’invecchiamento comincia a produrre vulnerabilità. La disponibilità dei ricambi può ridursi, le competenze necessarie alla manutenzione possono diventare rare, il vendor può interrompere il supporto, le interfacce possono non essere compatibili con le nuove piattaforme e l’applicazione di patch di sicurezza può diventare difficile o impossibile.
È quindi utile distinguere l’anzianità dall’obsolescenza. La prima è una caratteristica temporale. La seconda descrive una condizione nella quale mantenere il sistema affidabile, sicuro e conforme richiede uno sforzo crescente oppure non può più essere garantito con sufficiente confidenza.
Quando un sistema legacy diventa un rischio?
L’età, da sola, non rende inadeguato un sistema. Alcuni segnali indicano però che l’obsolescenza sta assumendo rilevanza industriale.
Il vendor non fornisce più supporto o aggiornamenti di sicurezza; hardware e ricambi diventano difficili da reperire; il sistema operativo non è più supportato; le competenze necessarie alla manutenzione sono concentrate in poche persone; aumentano le difficoltà di integrazione con sistemi più recenti; patch e aggiornamenti non possono essere applicati senza interventi complessi; backup e recovery dipendono da tecnologie non più facilmente disponibili.
La presenza di uno di questi elementi non impone automaticamente la sostituzione. Richiede però una valutazione strutturata del rischio e una strategia che definisca misure compensative, priorità e tempi di modernizzazione.
Il problema emerge quando OT e IT si incontrano
Per molti anni le tecnologie operative degli stabilimenti hanno funzionato in ambienti relativamente isolati. PLC, sistemi SCADA, Distributed Control System e altre componenti di automazione erano progettati soprattutto per garantire disponibilità, continuità e controllo del processo.
La digitalizzazione ha progressivamente modificato questa architettura. I dati devono essere trasferiti verso historian, MES, sistemi di analisi, piattaforme di manutenzione e applicazioni aziendali. La separazione tra Operational Technology e Information Technology diventa quindi meno netta.
Questa maggiore connettività crea opportunità importanti, ma modifica anche il profilo di rischio.
Il NIST, nella guida dedicata alla sicurezza dell’Operational Technology, sottolinea proprio la necessità di proteggere questi ambienti tenendo conto delle loro specifiche esigenze di performance, affidabilità e sicurezza. Un sistema OT non può essere trattato semplicemente come un normale computer aziendale: un aggiornamento, un riavvio o un intervento di cybersecurity possono avere conseguenze dirette sulla disponibilità del processo industriale.
Nel gennaio 2026 il NIST ha inoltre avviato il processo di revisione della propria guida SP 800-82 per tener conto dell’evoluzione delle minacce e delle pratiche di cybersecurity OT. È un segnale di quanto rapidamente stia cambiando un ambito nel quale gli asset industriali hanno invece cicli di vita molto lunghi.
Quando una patch non è un semplice aggiornamento
Il patch management rappresenta bene la particolarità del problema farmaceutico. In un ambiente IT tradizionale, installare rapidamente gli aggiornamenti di sicurezza è una delle misure fondamentali per ridurre l’esposizione alle vulnerabilità note. In un ambiente produttivo regolato, la stessa operazione deve considerare compatibilità, disponibilità dell’impianto e possibile impatto sullo stato validato del sistema.
Non significa che i sistemi GxP non debbano essere aggiornati. Significa che l’aggiornamento deve essere governato.
Prima di modificare un componente occorre comprendere quale funzione svolga, quali dati gestisca, quali interfacce coinvolga e quali conseguenze possa avere la modifica. In alcuni casi saranno sufficienti test mirati e documentazione del change; in altri sarà necessario un intervento di verifica più ampio.
Quando invece una patch non può essere installata perché il software non è più supportato o perché potrebbe compromettere il funzionamento dell’applicazione, il problema diventa quello delle misure compensative: segmentazione della rete, restrizione degli accessi, monitoraggio, controllo delle connessioni remote e altre misure proporzionate al rischio.
L’obiettivo non è mantenere immutato il sistema a ogni costo. È mantenere sotto controllo il rischio mentre si decide come e quando intervenire.
Compliance e cybersecurity convergono
Per molto tempo cybersecurity e compliance GMP sono state gestite come discipline sostanzialmente separate. La crescente digitalizzazione degli impianti rende questa separazione sempre meno sostenibile.
Un accesso non autorizzato può compromettere disponibilità e integrità dei dati. Una vulnerabilità di un sistema industriale può incidere sulla continuità produttiva. Una configurazione non adeguatamente controllata può avere conseguenze tanto sulla sicurezza informatica quanto sull’affidabilità delle registrazioni GxP.
PIC/S, nella guidance PI 041-1 dedicata alla data integrity, dedica specifica attenzione ai sistemi computerizzati e ribadisce che qualification e validation devono essere condotte in accordo con i requisiti GMP/GDP applicabili. La gestione del dato non può quindi essere separata dall’ambiente tecnologico nel quale quel dato viene generato, elaborato e conservato.
Anche il quadro europeo sta evolvendo. La revisione di Annex 11 sui sistemi computerizzati è stata avviata proprio per aggiornare un testo nato in un contesto tecnologico molto diverso da quello attuale e affrontare con maggiore profondità aspetti come gestione del ciclo di vita, cybersecurity, data integrity e tecnologie contemporanee.
Il principio che emerge è chiaro: la robustezza di un processo digitale dipende contemporaneamente dalla qualità del sistema, dalla gestione dei dati e dalla capacità di proteggerlo.
Il rischio nascosto dei ricambi e delle competenze
L’obsolescenza non riguarda soltanto il software. Un componente elettronico può uscire di produzione. Una scheda di controllo può diventare difficile da reperire. Il produttore di un’apparecchiatura può cessare l’attività oppure interrompere il supporto di una determinata generazione di sistemi.
Esiste poi un’altra forma di obsolescenza, meno evidente: quella delle competenze. Tecnologie installate vent’anni fa possono essere perfettamente conosciute da pochi tecnici che le hanno seguite per gran parte della loro vita professionale. Quando quelle persone cambiano ruolo o lasciano l’azienda, una parte della conoscenza necessaria alla manutenzione rischia di scomparire.
Il problema assume quindi una dimensione organizzativa. Documentazione tecnica, configurazioni, backup, logiche di controllo, procedure di recovery e conoscenza delle modifiche effettuate nel tempo devono essere gestiti come patrimonio aziendale e non restare affidati alla memoria di singoli specialisti.
La continuità tecnologica dipende anche dalla continuità della conoscenza.
Retrofit o sostituzione
Arriva infine il momento in cui l’azienda deve decidere se modernizzare il sistema esistente oppure sostituirlo.
Il retrofit può consentire di preservare apparecchiature ancora valide intervenendo su automazione, controllo, interfacce o componenti diventati obsoleti. Può ridurre investimenti e tempi rispetto alla sostituzione completa e limitare l’impatto sull’infrastruttura produttiva. Non è però sempre la soluzione migliore.
Aggiornamenti successivi possono creare architetture molto complesse, nelle quali tecnologie di generazioni differenti devono continuare a comunicare. Il costo di manutenzione può aumentare e la gestione delle interfacce diventare progressivamente più difficile.
La sostituzione completa richiede generalmente investimenti maggiori e può comportare tempi di fermo, qualification e validation più impegnative. Offre però l’opportunità di ripensare l’architettura del sistema, eliminare dipendenze tecnologiche accumulate nel tempo e creare una piattaforma più sostenibile per gli anni successivi.
La scelta non può quindi essere ridotta al confronto tra costo del retrofit e costo di una nuova macchina. Deve considerare il Total Cost of Ownership, la disponibilità futura del supporto, la cybersecurity, la manutenibilità, le esigenze di integrazione e il rischio operativo.
L’obsolescenza va gestita prima che diventi un’emergenza
Aspettare che un sistema legacy si guasti definitivamente è probabilmente il modo più costoso di affrontare il problema.
Una strategia più matura parte dalla conoscenza del patrimonio installato. Hardware, software, firmware, sistemi operativi, versioni, interfacce, vendor e stato del supporto dovrebbero essere censiti e valutati periodicamente.
Questo permette di individuare gli asset che stanno entrando in una fase critica e programmare gli interventi prima che l’azienda si trovi davanti a una scelta obbligata.
Il lifecycle management tecnologico diventa così parte della gestione del rischio industriale. Non si tratta di sostituire continuamente sistemi funzionanti, ma di conoscere la loro traiettoria di obsolescenza e decidere con anticipo dove investire.
Anche la relazione con i fornitori cambia. Nella selezione di una nuova tecnologia, la valutazione non dovrebbe limitarsi alle prestazioni iniziali. Disponibilità degli aggiornamenti, politica di cybersecurity, durata prevista del supporto, possibilità di migrazione dei dati e apertura delle interfacce possono diventare criteri altrettanto importanti.
Modernizzare senza perdere ciò che funziona
La trasformazione digitale del pharma viene spesso raccontata attraverso nuove fabbriche, intelligenza artificiale, digital twin e sistemi avanzati di automazione. La realtà industriale è molto più graduale. Gran parte dell’innovazione dovrà essere introdotta in stabilimenti esistenti, nei quali convivono tecnologie installate in periodi diversi.
La vera sfida sarà quindi modernizzare senza considerare automaticamente vecchio tutto ciò che è precedente e senza mantenere indefinitamente sistemi solo perché continuano a funzionare.
Un impianto legacy può avere ancora molti anni di vita utile. Ma la sua sostenibilità dipende dalla possibilità di mantenerlo sicuro, supportabile, integrabile e conforme. L’obsolescenza diventa critica quando riduce questa possibilità.
Gestirla significa conoscere gli asset, valutarne il rischio e programmare l’evoluzione tecnologica prima che sia un guasto, una vulnerabilità o l’indisponibilità di un ricambio a imporre la decisione.
In una fabbrica regolata, innovare non significa necessariamente sostituire. Significa soprattutto sapere quando continuare, quando aggiornare e quando è arrivato il momento di cambiare.
