Nel novembre 2026 la FDA ha introdotto un meccanismo per consentire l’aggiornamento iterativo dei modelli di intelligenza artificiale (AI) dopo l’autorizzazione, ma la realtà del mercato dimostra che pochi lo stanno effettivamente utilizzando. Uno studio pubblicato a maggio 2026 sul JAMA Health Forum ha rilevato che solo 43 dispositivi abilitati all’AI su 794 (5,4 %) autorizzati tra il 2023 e il 2025 disponevano di un Predetermined Change Control Plan (PCCP) approvato dalla FDA. La normativa è pronta ad accettare aggiornamenti pianificati e pre‑revisionati, ma l’industria sembra averci chiuso gli occhi.

Perché il PCCP non è sufficiente da solo

Il problema non risiede nella riluttanza della FDA a concedere i PCCP, bensì nella difficoltà delle aziende di mantenere la promessa scritta di un protocollo di modifica ripetibile lungo l’intero ciclo di vita del prodotto. La maggior parte dei team possiede dati, un modello e una validazione una tantum, ma manca dell’infrastruttura necessaria per eseguire nuovamente il processo di addestramento, validazione e distribuzione in modo controllato e tracciabile.

Il PCCP è il permesso normativo a iterare; l’MLOps è la capacità ingegneristica che rende possibile tale iterazione. Inseguire l’uno senza costruire l’altro equivale a trasformare l’innovazione in obsolescenza.

Dove il parallelo con il DevOps si interrompe

In ambito medicale, ogni software connesso è distribuito attraverso una pipeline che costruisce, testa, firma e traccia ogni rilascio, come richiesto dalla norma IEC 62304. Tuttavia, il modello AI di un dispositivo diagnostico di solito arriva dal gruppo di data science sotto forma di notebook esportato e di file di pesi, privo di:

    • una run di addestramento riproducibile,
    • tracciamento della provenienza dei dati,
    • un gate automatizzato tra risultato promettente e artefatto rilasciato.

Il codice diventa ingegneria, il modello rimane un “progetto scientifico”. La differenza cruciale è che un rilascio di modello modifica il comportamento del dispositivo senza alterare una singola riga di codice: la build è verde, i test unitari passano, ma il dispositivo ora fornisce conclusioni diverse dallo stesso input. Le pipeline software tradizionali non rilevano tale cambiamento, perciò l’MLOps deve essere una disciplina a sé stante, non un semplice checkbox.

Il ciclo di vita dei dati come controllo di progettazione

Le linee guida FDA per i piani PCCP richiedono tre elementi fondamentali:

    • descrizione delle modifiche previste,
    • protocollo di modifica che spieghi sviluppo, validazione e implementazione,
    • valutazione dell’impatto sui rischi.

Il draft della FDA sul ciclo di vita dei dispositivi AI aggiunge ulteriori requisiti: tracciabilità dei dati, analisi del bias, validazione collegata alle affermazioni di etichettatura e monitoraggio delle prestazioni post‑mercato. Questa lista deve essere letta come un documento di requisiti ingegneristici.

Un protocollo di modifica che si limiti a “riaddestrare su nuovi dati e ri‑validare” è inutile se non è supportato da:

    • versionamento dei dati e registrazione della loro provenienza,
    • criteri di accettazione per nuovi dataset applicati prima dell’ingresso,
    • un harness di validazione che riesegua automaticamente lo stesso protocollo su ogni modello candidato.

Se il riaddestramento dipende dalla memoria di un operatore su quale versione dei dati utilizzare, non si ha un vero PCCP, ma solo una promessa.

Separare modello e software

Modello e software di hosting operano su “orologi” diversi. Una piattaforma diagnostica può subire una revisione completa del firmware una o due volte l’anno, mentre un modello AI autorizzato può giustificare aggiornamenti validati ogni trimestre, o più frequentemente se i dati lo richiedono.

Quando modello e software sono strettamente accoppiati, ogni modifica al modello comporta l’intero ciclo di rilascio del dispositivo: regressioni complete, documentazione esaustiva e distribuzione complessa. Questo porta le squadre a fermare l’iterazione per evitare l’onere operativo.

Decoupling significa trattare il modello come un componente controllato e rilasciabile in modo indipendente, con:

    • un artefatto di modello versionato, manifesto, firma e evidenze di validazione,
    • un’applicazione host che carica modelli come componenti “swap‑abili” con controlli di compatibilità,
    • automazione di distribuzione capace di mettere in staging, verificare e fare rollback del modello senza toccare il software host.

Questa architettura rispecchia le pratiche mature per firmware e configurazioni: il modello diventa un artefatto con ciclo di vita definito.

La catena di aggiornamento come superficie di attacco

Ogni meccanismo costruito per spingere aggiornamenti di modello verso una flotta di sistemi clinici rappresenta anche una potenziale vulnerabilità. Gli incidenti di cybersecurity recenti nel settore medtech dimostrano come la catena di distribuzione possa essere il punto debole più critico.

È necessario trattare il modello come parte della software supply chain:

    • pesi, dati di addestramento, codice delle feature e runtime devono comparire nella SBOM (Software Bill of Materials) e nel threat model,
    • gli artefatti di modello devono essere firmati al momento del build e verificati al caricamento, con controlli di integrità analoghi a quelli del firmware,
    • le aspettative di cybersecurity della FDA (sezione 524B) si applicano anche ai componenti addestrati, non solo al codice scritto.

Altre best practice includono:

    • principio del “least privilege” per le credenziali di deployment, limitate a singolo sito,
    • gate di approvazione umana prima di ogni promozione in produzione,
    • tracciamento a prova di manomissione di chi promuove quale modello, da quale run di addestramento, verso quali sistemi e quando.

Se gli agenti AI assistono nella costruzione o nel deployment, vanno sottoposti a standard più severi rispetto agli operatori umani: il diagnostic è affidabile solo quanto il percorso che ha consegnato l’ultimo modello.

Un modello “one‑and‑done” è destinato all’obsolescenza

Costruire un algoritmo efficace è la parte più semplice; il vero valore competitivo risiede nell’architettura che lo circonda. Un ciclo di vita dei dati automatizzato, un percorso di rilascio di modello decouplato e firmato, e una pipeline rinforzata al pari del dispositivo stesso trasformano il PCCP da semplice documento normativo a vantaggio operativo.

Immaginate due concorrenti: il primo dispone di un PCCP autorizzato e di una pipeline MLOps funzionante, aggiornando il modello ogni trimestre; il secondo presenta un nuovo modello solo mediante una nuova sottomissione FDA o rinuncia all’aggiornamento. Dopo anni, il secondo avrà un diagnostico che riflette evidenze cliniche datate, mentre il mercato percepirà le prestazioni del modello come una caratteristica in evoluzione, premiando il primo.

Come costruire la pipeline MLOps necessaria

Passi chiave per passare dalla promessa alla pratica:

    • Versionamento dei dati e tracciabilità: utilizzare sistemi di data lake con controlli di versione (ad es. Delta Lake, DVC) e registrare metadati di provenienza.
    • Run di addestramento riproducibili: definire pipeline CI/CD per AI (ad es. Kubeflow, MLflow) che catturino parametri, codice, dipendenze e risultati in artefatti versionati.
    • Validazione automatizzata: implementare test di performance, bias, robustness e confronti contro baseline in modo continuativo.
    • Manifesti e firme per i modelli: generare manifesti contenenti hash, versioni, requisiti di compatibilità e firmarli digitalmente prima del rilascio.
    • Distribuzione controllata: utilizzare orchestratori (ad es. ArgoCD, Spinnaker) per distribuire modelli a dispositivi in modalità “canary” con rollback automatico.
    • Monitoraggio post‑mercato: raccogliere metriche di performance in campo, rilevare drift dei dati e attivare trigger di riaddestramento secondo il PCCP.
    • Sicurezza della catena: integrare scanning di vulnerabilità, SBOM, firma di artefatti e audit trail a livello di pipeline.

Implementare questi elementi richiede investimento iniziale, ma riduce drasticamente il carico di lavoro per ogni sottomissione successiva e consente di mantenere il dispositivo al passo con le evidenze cliniche emergenti.

Conclusioni

Il PCCP rappresenta una svolta normativa che apre la porta all’iterazione continua dei modelli AI nei dispositivi medici. Tuttavia, senza una robusta strategia MLOps, la promessa rimane vuota. Le aziende devono trasformare il ciclo di vita dei dati in un controllo di progettazione, separare modello e software, e proteggere la catena di aggiornamento come parte integrante della cybersecurity. Solo così il PCCP diventerà un vero vantaggio competitivo anziché una semplice formalità.