Rischi e validazione
Quadro dei rischi
| Rischio | Impatto | Probabilità se ignorato | Mitigazione |
|---|---|---|---|
| Soglie non validate clinicamente | Alto | Certa | Consulenza professionale prima di qualsiasi soglia |
| Falsa precisione percepita dall'utente | Alto | Alta | Arrotondamento, banda di incertezza, focus sul trend |
| Inquadramento come dispositivo medico | Alto | Media | Revisione legale dei claim prima del rilascio |
| Acquisizione non ripetibile | Medio-alto | Alta | Protocollo guidato + controlli automatici |
| Trattamento di dati sanitari | Alto | Media | Inferenza on-device, nessuna immagine trasmessa |
| Bias su corporature e popolazioni | Medio | Media | Test su campione eterogeneo, uscita esplicita in caso di bassa confidenza |
Validità clinica
Questo è il punto in cui il progetto ha davvero bisogno di competenza esterna.
Cosa non possiamo decidere internamente: quali angoli siano indicatori posturali significativi, quali intervalli siano da considerare normali, come pesarli in uno score complessivo, quali combinazioni meritino una segnalazione.
Sono decisioni di ambito sanitario. Prese da uno sviluppatore diventano numeri arbitrari con l'aspetto dell'autorevolezza — che è la modalità di fallimento peggiore, perché l'utente non ha modo di accorgersene.
Come vengono validati questi sistemi in letteratura. Gli studi che valutano l'attendibilità della pose estimation per uso posturale confrontano tipicamente le misure con un riferimento: sistemi di motion capture ottici con marker, oppure imaging radiografico per le misure di allineamento rachideo. Riportano poi accordo (correlazione, errore medio, limiti di concordanza) e affidabilità test-retest.
Una revisione della letteratura specifica per MediaPipe/BlazePose applicato alla valutazione posturale statica non è stata svolta in questa istruttoria. Prima di definire soglie va fatta, preferibilmente insieme al professionista che le validerà: serve a sapere quali articolazioni e quali piani di osservazione risultano affidabili e quali no.
Posizionamento difendibile. Il caso d'uso più solido non richiede validazione clinica assoluta: confrontare l'utente con se stesso nel tempo. Se il setup è costante, gli errori sistematici si cancellano nella differenza e la variazione osservata è informativa anche quando il valore assoluto non lo è. È anche il caso d'uso più utile in un contesto di allenamento.
Ripetibilità e calibrazione
Il test che va fatto per primo
Prima di qualunque discussione sulle soglie, va misurato quanto il sistema è coerente con se stesso:
Stessa persona, stesso setup, 10 acquisizioni consecutive con riposizionamento tra una e l'altra. Si calcola la deviazione standard di ciascun angolo.
Il risultato dice quale sia la più piccola variazione che il sistema può rilevare. Se la deviazione standard su un angolo è di 4°, quel sistema non può segnalare in modo sensato una deviazione di 2°: qualunque soglia più fine del proprio rumore produce solo falsi positivi.
Questo test costa pochi giorni e determina se il resto del progetto ha senso. È il primo spike proposto nei prossimi passi.
Calibrazione
Senza un riferimento di scala noto non esistono misure metriche (vedi il limite 3). Le opzioni, in ordine di attrito per l'utente:
| Approccio | Attrito | Affidabilità |
|---|---|---|
| Nessuna calibrazione, solo angoli e asimmetrie | Nessuno | Sufficiente per il caso d'uso principale |
| Altezza del soggetto inserita manualmente | Basso | Approssimativa: dà un ordine di grandezza, non una misura |
| Marker di dimensione nota nella scena (foglio A4, righello) | Medio | Buona, se il marker è complanare al soggetto |
| Distanza camera-soggetto fissata da protocollo | Medio | Buona, difficile da garantire nell'uso reale |
Raccomandazione: partire senza calibrazione, limitando l'output ad angoli e asimmetrie, e introdurre la calibrazione solo se emerge un requisito che la richiede davvero.
Protocollo di acquisizione
Le variabili da controllare, tutte con impatto diretto sul risultato: distanza dalla camera, altezza e inclinazione della camera, orientamento del soggetto rispetto all'obiettivo, posizione dei piedi, abbigliamento, illuminazione, sfondo.
L'utente non le controllerà spontaneamente. L'interfaccia deve renderle vincolanti: silhouette di allineamento, verifica che tutto il corpo sia nel frame, controllo di confidenza minima sui keypoint chiave, livella software, blocco dell'acquisizione finché le condizioni non sono soddisfatte. Meglio rifiutare un'acquisizione che produrre un numero inaffidabile.
Privacy e dati personali
Le immagini del corpo di una persona identificabile sono dati personali. Se il trattamento ha finalità di valutazione dello stato fisico, si entra nell'ambito dei dati relativi alla salute, categoria particolare ai sensi dell'art. 9 GDPR, con base giuridica più stringente del consenso ordinario.
L'architettura client-side riduce drasticamente il problema: se l'immagine non lascia il dispositivo e vengono trasmessi solo angoli, il trattamento lato server è molto più contenuto. Restano da presidiare:
- informativa chiara su cosa viene elaborato, dove e cosa viene conservato;
- base giuridica per lo storico delle misurazioni;
- retention definita e cancellazione effettiva su richiesta;
- valutazione della necessità di una DPIA — probabile se si conservano immagini o se si profilano utenti sullo stato fisico;
- attenzione particolare se tra gli utenti possono esserci minori (contesto sportivo).
"Gira nel browser quindi non ci sono problemi privacy" è vero solo finché nessuna immagine viene inviata o salvata. Basta una feature di condivisione con il trainer, o un salvataggio dello screenshot per il report, perché lo scenario cambi completamente.
Inquadramento regolatorio
È il rischio che più frequentemente viene scoperto tardi.
Nell'Unione Europea, un software destinato a diagnosi, prevenzione, monitoraggio, previsione, prognosi o trattamento di una condizione rientra nella definizione di dispositivo medico ai sensi del Regolamento (UE) 2017/745 (MDR). Il software che fornisce informazioni usate per prendere decisioni con finalità diagnostiche o terapeutiche è generalmente classificato in classe IIa o superiore secondo la Regola 11, con obblighi di certificazione sostanziali.
Il discrimine è la destinazione d'uso dichiarata — quello che si scrive nell'interfaccia, nella documentazione e nel materiale commerciale. La stessa identica tecnologia può stare dentro o fuori dal perimetro a seconda di come viene presentata:
| Formulazione | Area |
|---|---|
| "Monitora l'allineamento durante l'allenamento e osserva come cambia nel tempo" | Verosimilmente fitness/benessere |
| "Rileva deviazioni posturali e indica le anomalie da correggere" | Verosimilmente ambito medico |
Quanto sopra è un inquadramento sommario a uso interno, non un parere. La formulazione precisa dei claim va rivista da un legale prima del rilascio, non dopo. Il costo di rifrasare un'interfaccia in fase di design è nullo; quello di ritirare una funzionalità già pubblicata non lo è.
Indicazione operativa per il design: evitare termini clinici ("diagnosi", "patologia", "anomalia", "correzione") nei testi dell'interfaccia, evitare score presentati come esito sanitario, e includere un rimando esplicito al professionista sanitario per qualsiasi valutazione.
Bias e casi limite
I modelli sono addestrati su dataset fotografici la cui composizione determina dove funzionano meglio. Aspettarsi degrado su: corporature molto diverse dalla media del dataset, abbigliamento ampio o scuro su sfondo scuro, condizioni di illuminazione difficili, persone con disabilità motorie o arti amputati, soggetti seduti o in carrozzina.
Il problema non è il degrado in sé, ma che il modello non segnala di essere in difficoltà: restituisce comunque coordinate, con confidenza spesso non abbastanza bassa da far scattare un controllo. Serve un test su un campione volutamente eterogeneo e una soglia di confidenza oltre la quale l'applicazione dichiara di non poter valutare, invece di produrre un numero.