Dalla previsione all’azione responsabile: progettare l’incertezza nell’AI Femtech

Nel settore della salute delle donne, l’accuratezza è necessaria, ma rappresenta solo il primo livello di sicurezza del prodotto. È importante che il sistema sappia quando una previsione è abbastanza forte da essere utilizzata e sia progettato per dirlo quando non lo è.

Apri la maggior parte delle app di fertilità o di tracciamento del ciclo e vedrai un risultato pulito: ovulazione il giorno 15, un’etichetta di alta fertilità, un punteggio di confidenza del 78%. Il numero sembra preciso. La biologia sottostante non lo è.

Una data di ciclo mestruale è qualcosa che l’utente ha osservato. L’ovulazione è un evento latente che nessun dispositivo per consumatori misura direttamente. Viene inferita da proxy. La temperatura della pelle riflette non solo il progesterone, ma anche il sonno, l’alcol, la malattia, le condizioni ambientali e dove il sensore si trovava quella notte. Un inserimento di sintomi combina fisiologia con percezione, memoria e la decisione dell’utente di registrarla. Nel momento in cui tutto ciò si risolve in “Giorno 15, 78%”, diverse forme di incertezza sono state silenziosamente compresse in una frase che suona confidenziale.

Nei prodotti con cui ho lavorato nel settore della salute delle donne, il problema difficile non è l’accuratezza. Il modello a cui continuo a tornare è l’integrità della decisione. L’accuratezza ti dice quanto bene un modello prevede. Non dice nulla su se il prodotto sa quando una previsione è abbastanza forte da essere utilizzata. In un dominio in cui la stessa output può informare la pianificazione casuale o una decisione contraccettiva, è lì che si vince o si perde la fiducia.

Quindi il mio argomento è che l’AI Femtech non ha principalmente bisogno di una previsione migliore. Ha bisogno di una progettazione dell’incertezza migliore. E la progettazione dell’incertezza non è una clausola aggiunta prima del lancio; è un’architettura. La strutturo in sei livelli che portano un segnale da input grezzo a un’azione che il sistema può giustificare e verificare. Applico una versione a sei livelli del Metodo di Decisione-azione del Prodotto Calibrato, progettato per governare come i segnali di salute incerti vengono convertiti in azioni permesse e responsabili. Il metodo include la qualificazione dei dati, la calibrazione dell’inferenza, la mappatura delle conseguenze, la politica di controllo, l’esecuzione del flusso di lavoro e un ciclo di responsabilità. Il suo percorso di governo inizia con i dati sanitari, che portano all’architettura della decisione e culminano in un’azione responsabile.

1. Qualificare i dati prima di fidarsi

Il primo livello decide cosa il sistema sa effettivamente. I prodotti Femtech attingono da fonti molto diverse. Possono includere cose che l’utente ha osservato direttamente, come date di ciclo mestruale o rapporti soggettivi come dolore o umore, nonché caratteristiche indossabili come temperatura della pelle e variabilità della frequenza cardiaca, e variabili generate dal modello stesso. Trattare questi come input intercambiabili è il peccato originale.

Ogni segnale necessita di una provenienza che il sistema possa leggere: da dove proviene, quando, con quale frequenza viene campionato, cosa lo confonde e come si relaziona con la cosa che stai effettivamente prevedendo. L’ovulazione è l’evento. La temperatura, il muco cervicale, l’LH e le date del ciclo sono prove di quell’evento, ognuno con il proprio ritardo e il proprio errore.

I dati mancanti meritano un’attenzione particolare perché, nella registrazione della salute, non sono raramente casuali. Le persone registrano di più quando sono preoccupate e smettono quando si sentono bene, quindi una lacuna può portare tanto quanto un inserimento. In un’analisi del mondo reale di oltre 600.000 cicli ovulatori, l’ovulazione non poteva essere rilevata in 665.603 dei 1,4 milioni di cicli inizialmente considerati. Tre quarti di questi avevano letture di temperatura valide su meno della metà dei giorni del ciclo. La sufficienza dei dati era un fattore limitante importante per ciò che l’algoritmo poteva inferire. Un prodotto che emette un’etichetta di fertilità pulita in quella situazione non sta essendo confidenziale. Sta fabbricando una precisione che non possiede.

2. Calibrare l’inferenza con le prove

Un singolo punteggio di confidenza non può rappresentare ciò che sta realmente accadendo, perché questi sistemi affrontano diverse fonti di incertezza contemporaneamente. Queste includono la variabilità biologica nel processo stesso, la qualità della misurazione, la mancanza di auto-registrazione, l’incertezza del modello dai dati di formazione sottili e lo spostamento di distribuzione quando l’utente attuale non assomiglia alla popolazione con cui il modello è stato validato.

Nell’analisi sopra menzionata, solo il 13% dei cicli era esattamente di 28 giorni e la fase follicolare media durava 16,9 giorni in un intervallo abbastanza ampio da rendere qualsiasi assunzione fissa di “giorno 14” fuorviante. Lo Studio sulla salute delle donne di Apple ha trovato che la lunghezza del ciclo e la variabilità all’interno della persona erano associate all’età, all’etnia autodichiarata e all’indice di massa corporea. La personalizzazione, quindi, non può significare sostituire una media di popolazione con un singolo punto personale. Significa produrre una distribuzione che si stringe man mano che si accumulano le prove.

Considera due previsioni basate sull’AI che entrambe leggono “75%”. Una si basa su un anno di storia e misurazioni dense, e la sua incertezza è principalmente biologia reale. L’altra si basa su due cicli, cinque letture di temperatura, viaggio recente e farmaci sconosciuti. Qui, l’incertezza è principalmente dovuta ai dati mancanti. Stesso numero. Il prodotto non dovrebbe essere autorizzato a rispondere allo stesso modo. Questo è anche il motivo per cui la calibrazione deve essere verificata all’interno dei sottogruppi – le prestazioni aggregate possono nascondere un modello che è eccessivamente confidenziale, in particolare per cicli irregolari o utenti in perimenopausa. La letteratura clinica-AI separa ora discriminazione, calibrazione e utilità decisionale per questo motivo esatto. Un modello può classificare bene gli utenti e ancora produrre probabilità incorrette per decisioni reali.

3. Mappare le conseguenze dell’essere sbagliato

Il terzo livello chiede cosa accade quando il sistema è sbagliato e lega la risposta consentita a quel costo. Un riassunto del ciclo, una stima della finestra fertile, un’etichetta di bassa fertilità letta come guida contraccettiva e un’interpretazione dei sintomi che decide se qualcuno cerca cure non sono lo stesso prodotto, anche quando il modello dietro di essi è identico.

Suddivido le output in quattro livelli per conseguenza: informativo, comportamentale, riproduttivo e clinico. Ognuno ha la sua soglia di prova, linguaggio consentito e percorso di escalation. Una probabilità del 70% potrebbe essere sufficiente per indovinare quando inizia un ciclo mestruale e non essere nemmeno lontanamente sufficiente per rassicurare qualcuno che cerca di non rimanere incinta.

Questo è dove il design incontra la regolamentazione. Se il software entra nel territorio dei dispositivi medici dipende dall’uso previsto e dal ruolo che la sua output gioca in una decisione sanitaria. La guida attuale dell’FDA sul software di supporto alle decisioni cliniche, aggiornata a gennaio 2026, è esplicita che le funzioni destinate ai pazienti e ai caregiver possono soddisfare la definizione di dispositivo. La posizione regolamentare non è una revisione legale alla fine. È codificata nelle tue soglie, nel tuo linguaggio e nella tua logica di escalation fin dal primo giorno.

4. Trasformare l’incertezza in una politica di controllo

Un’etichetta generica “i risultati possono essere inaccurati” consegna l’intero problema di interpretazione all’utente. Una politica di controllo fa l’opposto. Per uno stato di prova dato, decide se il sistema mostra un’osservazione, offre un intervallo limitato, chiede un’altra misurazione, punta a un clinico o rifiuta di rispondere. L’astensione è una capacità del prodotto, non un fallimento. “Non siamo sicuri ancora” dovrebbe essere uno stato progettato con un passo successivo, non uno schermo di errore.

Concretamente, invece di “Ovulazione: Giorno 15, Confidenza 78%”, una risposta governata legge più o meno così: l’ovulazione è più probabile all’interno di una finestra di quattro giorni; la confidenza è limitata dai dati di temperatura mancanti e dal sonno disturbato; alcune letture aggiuntive affinerebbero la stima e un test LH potrebbe aggiungere prove prospettiche e restringere la finestra probabile. L’utente ottiene una stima, il motivo per cui è incerta e l’azione singola che la cambierebbe.

5. Sostenere l’azione che l’output implica

Anche un’app consumer crea un flusso di lavoro: registrare un’altra lettura, ripetere un test, continuare a osservare, esportare dati, chiamare un clinico. Il sistema dovrebbe sapere quale azione ogni risposta punti e se può supportare quell’azione in modo sicuro.

Il confine tra la guida del prodotto e il consiglio medico vive qui e non è una linea fissa. Il contenuto educativo che spiega cosa significhi generalmente un segnale si trova saldamente sul lato della guida. Il prodotto si sposta in un territorio a più alto rischio nel momento in cui interpreta i dati di una persona come malattia, dirige il trattamento o offre rassicurazioni che portano un peso clinico reale. Quel confine deve essere mantenuto in ogni interazione, non solo nei termini di servizio.

6. Chiudere il ciclo di responsabilità

L’ultimo livello giudica l’intero sistema, non solo il modello. Le metriche standard del modello continuano a essere importanti e si concentrano sulla discriminazione, sulla calibrazione, sulla prestazione dei sottogruppi, sulla convalida esterna e temporale. Ma le metriche a livello di prodotto sono altrettanto importanti. Dovremmo chiedere con quale frequenza il sistema ha avuto abbastanza input per agire, con quale frequenza si è astenuto. Inoltre, ce n’è uno che insisterei: il tasso di rassicurazione falsa, ovvero con quale frequenza ha detto a qualcuno che tutto sembrava a posto sulla base di prove che non potevano sostenere l’affermazione.

Ogni risposta consequenziale dovrebbe essere ricostruibile a posteriori. Regolatori, organismi di standardizzazione e istituzioni di governance sanitaria globale stanno adottando sempre più questa visione del ciclo di vita. I principi di buona pratica dell’apprendimento automatico dell’IMDRF trattano l’AI sanitaria affidabile come una responsabilità del ciclo di vita totale che copre progettazione, distribuzione e monitoraggio, facendo eco alla guida dell’OMS sull’AI per la salute.

Come appare l’architettura nella pratica

Supponi che un prodotto abbia tre mesi di date del ciclo mestruale, sei notti di temperatura, un test LH positivo, una dispersione di inserimenti di sintomi e una settimana di sonno disturbato. La probabilità di ovulazione più alta del modello cade sul giorno 15. Un’app che fornisce una stima puntiforme mostra “Ovulazione: Giorno 15, Confidenza 78%”.

L’architettura produce qualcosa di diverso. Segna i dati di temperatura come sparsi e confusi dal sonno. Genera una distribuzione su diversi giorni candidati invece di uno. Applica una soglia gentile per la consapevolezza del ciclo, ma una più rigida se l’output tocca la prevenzione della gravidanza. Offre un intervallo più della prossima misurazione utile. E memorizza l’intero stato di prova in modo che la decisione possa essere ricostruita in seguito. Stesso modello sottostante e prodotto molto diverso.

Il diritto di agire

I sistemi Femtech stanno diventando sempre più ricchi di dati, con app, dispositivi indossabili, test casalinghi, registri medici e strati conversazionali sovrapposti. Più dati possono affinare l’inferenza, ma allargano anche la superficie per la precisione falsa. Le squadre che guadagnano la fiducia non saranno quelle con il punteggio di confidenza più pulito. Saranno quelle il cui prodotto sa cosa non sa e è costruito per dirlo.

L’accuratezza descrive la qualità di una previsione. L’integrità della decisione decide se il prodotto ha guadagnato il diritto di agire su di essa.