Il Sensore e la Soglia

Un dispositivo wearable di nuova generazione - un cinturino che misura la frequenza cardiaca, la variabilità del battito (heart rate variability o HRV), la saturazione dell'ossigeno, l'attività elettrodermica, la temperatura periferica e la qualità del sonno - produce, in ventiquattro ore, dell'ordine di sette-dieci milioni di campioni biometrici. Quei campioni, attraversata una pipeline di acquisizione edge, filtraggio adattivo, estrazione di feature e inferenza di un modello di apprendimento automatico, vengono ricondotti a una decisione: anomalia o normalità, allerta o silenzio, engagement o sospensione. Tra il segnale crudo del sensore e l'attivazione della soglia decisionale si interpone un'architettura ingegneristica che - dal 2 agosto 2026 - opera sotto un regime giuridico nuovo: il Regolamento UE 2024/1689 sull'intelligenza artificiale, comunemente noto come AI Act, in regime di piena applicabilità per i sistemi ad alto rischio (Regulation EU 2024/1689).

La domanda ingegneristica che si pone è precisa. Quali sensori, quali algoritmi, quali soglie di confidenza qualificano un dispositivo wearable per uso consumer come uso wellness, e quali invece - per finalità d'uso, modalità di marketing o capacità diagnostiche dichiarate - lo collocano sotto la qualificazione di dispositivo medico ai sensi del Regolamento UE 2017/745 (MDR) e, contestualmente, sotto la classificazione high-risk dell'Allegato III dell'AI Act? La risposta non è di principio ma di progetto: è l'architettura del sistema, non la dichiarazione del produttore, a determinarne la qualificazione giuridica (Pesapane et al., 2018; Muehlematter et al., 2021).

Questo articolo traccia il filo che lega il sensore alla soglia - dai principi di sensor fusion alle metriche di calibrazione del classificatore, dai requisiti di sorveglianza umana all'audit post-market - e mostra come la soglia decisionale di un wearable medicale non sia un iperparametro da ottimizzare in laboratorio, ma una scelta architetturale soggetta a vincoli normativi multipli, convergenti, e oggi compresenti.

§1. Il sensore come strumento di misura e l'incertezza ineliminabile

La metrologia clinica insegna una regola che la cultura di consumo tende a dimenticare: nessuna misurazione è esatta. Ogni sensore biomedico - fotopletismografico (PPG), elettrocardiografico (ECG), accelerometrico inerziale (IMU), ottico per la saturazione (SpO₂), elettrodermico (EDA), termico - possiede una funzione di trasferimento caratterizzata da rumore termico, drift temporale, errore sistematico dipendente dalla pelle e dalla pressione di contatto, sensibilità all'artefatto di movimento, banda passante limitata. La letteratura ingegneristica delle tecnologie indossabili (Fabbrizio et al., 2023; Patel et al., 2012) ha consolidato una caratterizzazione metrica per ciascun canale: l'accuratezza tipica di un sensore PPG da polso nella stima del battito cardiaco in condizioni di quiete si attesta su un errore medio assoluto di ±2-3 battiti al minuto, che cresce a ±10-15 in attività ad alta intensità.

L'incertezza di misura è il dato di partenza, non una imperfezione residua. Da essa discende il primo principio architetturale di qualsiasi pipeline wearable: l'output decisionale non può essere più preciso dell'input. Una rete neurale addestrata a classificare aritmie da segnale PPG con accuratezza nominale del 99,5% su dataset di laboratorio incontra, nel mondo reale, un degrado prestazionale documentato (Bayoumy et al., 2021) che può arrivare al 15-25% in popolazioni e contesti non rappresentati nel dataset di addestramento. La differenza tra il valore pubblicato sul paper e il valore osservato nel deployment è ciò che la letteratura della validazione clinica chiama performance gap.

La pipeline ingegneristica tipica si articola, da monte a valle, in stadi canonici: sensing multimodale (uno o più canali sincronizzati), pre-processing (rimozione di artefatti, filtraggio passa-banda, baseline correction), feature extraction (parametri tempo-frequenza, indici di non linearità, descrittori di forma d'onda), fusione multimodale (precoce, tardiva o ibrida), inferenza (modello di classificazione o regressione), soglia (calibrazione del cut-off operativo), azione (notifica utente, alert clinico, integrazione in cartella sanitaria elettronica). Ciascuno stadio possiede metriche di qualità tracciabili e, sotto AI Act, soggette a obbligo di registrazione (logging, art. 12) e documentazione tecnica (Allegato IV).

§2. La sensor fusion e la geometria della decisione

Il singolo canale è quasi sempre insufficiente. La pratica ingegneristica matura ha mostrato che la robustezza decisionale di un wearable medicale dipende dalla capacità di integrare canali eterogenei in una rappresentazione coerente - la sensor fusion (Hall & Llinas, 1997; Khaleghi et al., 2013). La tassonomia consolidata distingue tre livelli: fusione a livello dato (concatenazione di campioni grezzi pre-allineati temporalmente), fusione a livello feature (concatenazione di descrittori estratti indipendentemente), fusione a livello decisione (combinazione di output di classificatori specializzati, tipicamente via voting, stacking o Dempster-Shafer evidence theory). Ogni livello implica un compromesso diverso tra ricchezza informativa, costo computazionale, latenza, graceful degradation al guasto di un sensore.

L'approccio architetturale di riferimento per i wearable medicali contemporanei è la fusione tardiva probabilistica (Fucarino et al., 2024): ciascun canale alimenta un classificatore specializzato che produce una distribuzione di probabilità calibrata, e una funzione di combinazione bayesiana o evidence-theoretic produce la decisione finale. La logica progettuale è chiara: la fusione tardiva isola il guasto. Se il sensore PPG perde contatto, il classificatore associato emette un segnale di bassa confidenza che la funzione di combinazione recepisce, riducendo il peso del canale degradato. Il sistema continua a operare ma comunica con onestà - al modello a valle e all'operatore clinico - che la decisione si è formata su evidenza parziale.

La soglia è il punto in cui la rappresentazione probabilistica continua si trasforma in azione discreta. La sua scelta è geometricamente equivalente alla tracciatura di un iperpiano nello spazio delle feature, e operativamente equivalente alla definizione del compromesso tra falsi positivi e falsi negativi. Per un wearable cardiovascolare, una soglia troppo permissiva genera alert fatigue clinica - l'operatore impara a ignorare le notifiche; una soglia troppo restrittiva manca eventi clinici critici. La calibrazione corretta non è un esercizio di ottimizzazione a costo zero: richiede curve ROC stratificate per sottogruppo demografico, calibrazione attiva post-deployment (Platt scaling, isotonic regression), e - sotto AI Act - registrazione tracciabile delle variazioni della soglia con il loro razionale clinico (art. 9, sistema di gestione del rischio).

§3. La qualificazione regolamentare: dispositivo medico e classificazione di rischio

Un wearable è un dispositivo medico, ai sensi dell'art. 2(1) del Regolamento UE 2017/745 (MDR), quando è destinato dal fabbricante a una finalità medica specifica - diagnosi, prevenzione, monitoraggio, prognosi, trattamento, alleviamento di una malattia o di una lesione. La qualificazione non dipende dalla tecnologia ma dall'intended use dichiarato e dalla rappresentazione che il fabbricante ne dà sul mercato (Pesapane et al., 2018). Un dispositivo identico, materialmente parlando - stesso sensore, stessi algoritmi, stesso firmware - può essere commercializzato come prodotto wellness (al di fuori del perimetro MDR) o come dispositivo medico (dentro il perimetro). La differenza è una decisione editoriale del fabbricante, ma le conseguenze sono ingegneristiche: il dispositivo medico richiede un sistema di gestione della qualità conforme a ISO 13485, una valutazione clinica documentata, un sistema di sorveglianza post-market, un dossier tecnico approvabile da un organismo notificato.

Dal 2 agosto 2026, l'AI Act sovrappone una seconda qualificazione. L'art. 6(1) e l'Allegato I qualificano automaticamente come high-risk i sistemi di intelligenza artificiale che sono componenti di sicurezza di dispositivi medici già sottoposti a valutazione di conformità da parte di terzi. La doppia qualificazione - MDR più AI Act high-risk - non è un duplicato ma una stratificazione: il dispositivo deve soddisfare requisiti medico-dispositivi (sicurezza, prestazione, valutazione clinica) e requisiti AI-specifici (qualità dei dati, robustezza, accuratezza, sorveglianza umana, trasparenza, logging). Il Recital 51 dell'AI Act chiarisce che la classificazione high-risk ai sensi del Regolamento non comporta automaticamente classificazione di rischio elevato ai sensi del MDR, ma - come la pratica delle pubblicazioni di settore ha messo in evidenza (Pesapane, Iuliano et al., 2025) - le due architetture di conformità si sovrappongono ampiamente nei vincoli ingegneristici.

I requisiti dell'AI Act per i sistemi high-risk, sintetizzati negli articoli 8-15, costituiscono una specifica tecnica di progetto: sistema di gestione del rischio iterativo lungo l'intero ciclo di vita (art. 9), data governance con dataset di addestramento, validazione e test caratterizzati per rappresentatività, completezza e assenza di errori (art. 10), documentazione tecnica conforme all'Allegato IV (art. 11), registrazione automatica degli eventi (art. 12), trasparenza verso l'utilizzatore (art. 13), sorveglianza umana progettata nel sistema (art. 14), accuratezza, robustezza e cybersecurity misurabili (art. 15). Lo standard ISO/IEC 42001 sui sistemi di gestione dell'intelligenza artificiale, pubblicato nel dicembre 2023, fornisce il modello organizzativo per assolvere a questi requisiti in modo verificabile, in parallelo a ISO 14971 sul risk management dei dispositivi medici.

§4. La sorveglianza umana e il problema del carico cognitivo clinico

L'art. 14 dell'AI Act qualifica la sorveglianza umana - human oversight - come requisito di progetto, non come dichiarazione di intenti. Il sistema deve essere progettato in modo che le persone fisiche cui è affidata la supervisione possano comprendere le capacità e i limiti del sistema, monitorarne il funzionamento, interpretarne correttamente l'output, decidere di non utilizzarlo, intervenire o interromperne il funzionamento. Si tratta di una specifica funzionale traducibile in interfacce, latenze ammissibili, contenuti informativi della notifica, percorsi di override.

Il problema operativo che la letteratura clinica ha identificato con crescente precisione è il carico cognitivo dell'operatore. Un medico di medicina generale che riceve, nell'arco di una settimana, qualche centinaio di alert da wearable dei propri pazienti - anomalie del ritmo, deviazioni della pressione, episodi notturni - non possiede il tempo necessario per la valutazione sostantiva di ciascuno. Il fenomeno dell'alert fatigue, documentato in oltre vent'anni di letteratura sui sistemi di supporto decisionale clinico (van der Sijs et al., 2006; Ancker et al., 2017), produce un effetto contro-intuitivo: la sorveglianza umana formalmente esistente diventa, sotto carico, una formalità procedurale. L'operatore conferma per default, salvo evidenze macroscopiche di errore. L'automation bias (Parasuraman & Manzey, 2010) chiude il ciclo: la fiducia acritica nel sistema si rinforza con il volume, non si erode.

La progettazione ingegneristica risponde con strumenti specifici, oggi parte dello stato dell'arte dei sistemi clinici di supporto decisionale. La triagiatura algoritmica degli alert raggruppa eventi correlati e li presenta in cluster anziché come notifiche isolate. La graduazione della confidenza separa visivamente alert ad alta probabilità di vera positività da quelli a bassa probabilità, attivando workflow differenziati. Il feedback loop chiuso tra esito clinico documentato e calibrazione della soglia, sostenuto da architetture di continuous learning regolamentate (FDA Good Machine Learning Practice, 2021; FDA Predetermined Change Control Plans, 2024), consente al sistema di apprendere dai propri errori senza violare il quadro di conformità statica. L'esperienza maturata su piattaforme di tele-esercizio (Iuliano, Zimatore, Fabbrizio et al., 2025) ha mostrato che l'efficacia clinica di un wearable cresce non con la sensibilità del sensore ma con l'adeguatezza del ciclo di feedback fra dispositivo, paziente e clinico.

La sorveglianza umana, in questa lettura, non è un veto periodico sul sistema autonomo: è una funzione di sistema che deve essere misurabile. Tempo medio di revisione per alert, tasso di override osservato, distribuzione dei motivi di override, correlazione fra override e esiti clinici a distanza temporale: questi sono i descrittori operativi della sorveglianza umana effettiva. La loro assenza nella documentazione tecnica trasforma l'art. 14 in una dichiarazione vuota - e l'AI Act non tollera dichiarazioni vuote.

§5. Il resto metrologico: la soglia come invariante di progetto

Si torni alla domanda iniziale. Il wearable raccoglie milioni di campioni; la pipeline ne distilla una decisione; la soglia trasforma una probabilità continua in azione discreta. Dove si colloca, in questa catena, il principio che il dispositivo è al servizio della persona, e non viceversa?

La risposta ingegneristica matura, oggi sostenuta dalla convergenza fra AI Act, MDR, ISO/IEC 42001 e linee guida FDA, è che il principio non si colloca in nessun punto specifico della pipeline - si colloca come invariante di progetto che il sistema deve soddisfare in ogni stato. La soglia non è un'opportunità di ottimizzazione: è il punto in cui il sistema riconosce di operare su un soggetto che eccede strutturalmente la propria rappresentazione statistica. La distribuzione di addestramento è finita, eterogeneità della popolazione reale è infinita, il caso individuale è - in misura sempre non nulla - out-of-distribution. Le tecniche di uncertainty quantification (calibrazione bayesiana, conformal prediction, ensemble disagreement) non eliminano questa eccedenza: la dichiarano, la quantificano, la trasformano in informazione operativa che la sorveglianza umana può effettivamente utilizzare.

Il punto metodologico è formulabile in modo asciutto: un sistema wearable medicale che decide su un soggetto deve sapere quando non sa, e fermarsi. La sospensione di sé stesso non è un fallimento del progetto - è una sua specifica funzionale, codificata nei protocolli di fallback verso human deliberation obbligatoria, segnalata all'operatore con linguaggio onesto, registrata nei log dell'art. 12 dell'AI Act. Un dispositivo che non sa fermarsi, in senso ingegneristico stretto, è un dispositivo mal progettato - e mal progettato, oggi, significa non conforme.

Tra il sensore e la soglia si interpongono milioni di campioni, decine di stadi di elaborazione, una matrice di confusione, una documentazione tecnica di centinaia di pagine, un organismo notificato, un fascicolo MDR e un dossier AI Act. Ma in fondo - al fondo che la pipeline non vede - c'è un soggetto. La maturità ingegneristica di un sistema indossabile per la salute non si misura nell'accuratezza del sensore: si misura nella sua capacità di non dimenticare quel soggetto in alcun punto della propria catena di elaborazione, nemmeno quando la pipeline produce output tecnicamente impeccabili.

Il sensore misura. La soglia decide. Ma fra la misura e la decisione, fra il campione e l'azione, fra il dato fisiologico e l'avviso clinico, vive una distanza che nessuna architettura può chiudere - e che ogni architettura ben fatta riconosce. La riga di codice più importante, anche in un wearable, è quella che sospende l'esecuzione e chiede a un essere umano di guardare.