Etica degli algoritmi significa valutare come un’app raccoglie, elabora e presenta informazioni che incidono su persone e decisioni. In termini semplici, un audit etico verifica trasparenza, giustizia e rispetto dell’utente lungo l’intero ciclo di vita del dato. L’obiettivo non è solo scovare abusi, ma costruire un linguaggio comune tra utenti tecnici, designer e sviluppatori per misurare ciò che conta.
È rilevante perché la combinazione di raccolta dati, modelli di ML e scelte di design influenza comportamenti, opportunità e fiducia. Un approccio sistematico permette di individuare rischi ricorrenti e di comunicarli con rigore. Questa guida propone: criteri di valutazione, una checklist tecnica sulla raccolta dati, strumenti per l’explainability, metriche di bias e un repertorio di dark patterns, oltre a un workflow operativo con tool open source.
Cornice etica e criteri di valutazione
Per incasellare l’audit, conviene fissare quattro pilastri: necessità (i dati richiesti servono davvero al servizio?), proporzionalità (quantità e sensibilità dei dati sono adeguate?), trasparenza (l’utente capisce cosa accade?) e controllo (può scegliere e revocare). Un criterio pratico è l’impattometria: stimare l’impatto potenziale su utenti vulnerabili, su decisioni economiche o su reputazione. Annotare per ogni funzione dell’app le finalità dichiarate, i dati trattati, le basi di legittimità e i meccanismi di opt-in/opt-out.
Una matrice di rischio utile combina due assi: probabilità di abuso e gravità del danno. Punteggi tipici da 1 a 5 per ciascun asse producono una classe di rischio (basso, medio, alto). Integrare note su persistenza dei dati, condivisione con terze parti e presenza di processi automatizzati ad alto impatto.
Raccolta dati e permessi: check tecnico
La verifica parte da permessi e traffico. Sul fronte Android, strumenti come Exodus Privacy, ClassyShark3xodus, Apktool e MobSF aiutano a ispezionare APK, tracker e chiamate. Per l’analisi del network si possono usare mitmproxy o Wireshark in un ambiente controllato. Su iOS, approcci con Frida o Objection supportano test dinamici su API e storage, nel rispetto delle leggi e dei termini d’uso.
Checklist essenziale dei permessi e della telemetria:
- Permessi non correlati alla funzione principale? (principio di minimizzazione)
- Dati sensibili inviati in chiaro o verso domini non documentati?
- Numero di tracker, tipi (analytics, ads, profiling) e granularità degli identificativi.
- Persistenza locale: uso di Keychain/Keystore, crittografia a riposo, rotazione dei token.
- Controlli utente: opt-in esplicito, revoca granulare, data portability.
Explainability dei modelli: cosa pretendere
Quando un’app incorpora modelli, l’audit valuta spiegabilità e verificabilità. A livello di modello, strumenti come LIME, SHAP, ELI5 o Captum forniscono feature attributions locali e globali. A livello di sistema, servono model cards con: finalità, dati di addestramento descritti ad alto livello, limiti noti, fasce d’uso sconsigliate e metriche di prestazione per segmenti rilevanti.
Elementi minimi da richiedere: disponibilità di spiegazioni comprensibili all’utente finale, canale di contestazione della decisione automatizzata e log di inferenza auditabili. In assenza di trasparenza, applicare una penalità di rischio nel punteggio complessivo e documentare l’incertezza.
Bias e metriche: come misurare
Il bias si misura con indicatori riproducibili. Tra i principali: disparate impact ratio (>= 0,8 come soglia indicativa), demographic parity (differenza nei tassi di selezione tra gruppi), equalized odds (gap in TPR/FPR), calibrazione per gruppo e predictive parity. Per classificatori, confrontare matrici di confusione per segmenti; per raccomandazioni, analizzare diversità e copertura tra cohort.
Procedura pratica:
- Definire gruppi protetti rilevanti e proxy eticamente gestibili.
- Campionare output su un periodo e calcolare TPR/FPR, PPV/NPV per gruppo.
- Stimare impatto economico e non economico dei falsi positivi/negativi.
- Stabilire soglie di allerta e un piano di mitigazione (riequilibrio dati, soglie differenziate, regole post-process).
Dark patterns: riconoscerli e segnalarli
I dark patterns sono scelte di design che indirizzano l’utente contro i propri interessi. Repertorio minimo: roach motel (iscrizione facile, uscita difficile), confirmshaming (colpa implicita nei rifiuti), nagging (solleciti ripetuti), preselezioni ingannevoli, forced action e privacy zuckering (spinte a condividere più del necessario). Documentare con screenshot, percorsi ripetuti e differenze tra versioni linguistiche.
Segnali di rischio: opzioni di rifiuto meno visibili, testo ambiguo nei consensi, interruttori che invertano le aspettative, incentivi economici per abilitare tracking, labelling confuso tra “necessario” e “facoltativo”. Assegnare un punteggio in base a frequenza, gravità e reversibilità dell’azione.
Strumenti open e workflow di audit nerd
Un flusso minimale ma robusto può seguire questi passi: raccolta evidenze tecniche (mitmproxy, Wireshark, MobSF), inventario permessi e tracker (Exodus, ClassyShark3xodus), mappatura dati e basi giuridiche, test di explainability su campioni con LIME/SHAP, calcolo metriche di bias, scansione UI per dark patterns. Centralizzare risultati in una risk register versionata, con evidenze allegabili e punteggi.
Metriche sintetiche utili:
- Permission Risk Score: somma pesata di permessi sensibili vs funzionalità core.
- Tracker Index: numero e tipologia di tracker con severità per destinazione.
- Model Risk Score: opacità del modello, impatto decisionale, possibilità di ricorso.
- Dark Pattern Density: occorrenze per schermata o per task critico.
- Exposure Surface: varietà di dati, tempi di ritenzione, condivisione con terzi.
Approfondimenti, eccezioni e trade-off
Non tutte le richieste di dati sono sospette: alcune funzioni richiedono permessi elevati per operare. In questi casi, la legittimità si valuta su minimizzazione, chiarezza della documentazione e possibilità di modalità ridotte. Anche l’explainability può essere limitata da proprietà intellettuale o sicurezza; ciò non esonera dal fornire ragioni comprensibili e canali di contestazione. Per il bias, la disponibilità di attributi sensibili può essere regolata: si possono adottare proxy trasparenti o procedure di verifica esterna su dataset sintetici.
Un audit etico efficace bilancia praticità e profondità: si parte da controlli leggeri e si intensifica dove i punteggi indicano rischio. L’elemento distintivo è la riproducibilità: stessi dati, stessi strumenti, stesse conclusioni.
Per passare dall’analisi all’azione, conviene creare un kit riutilizzabile: script per l’estrazione dei permessi, profili di mitmproxy preconfigurati, notebook per calcolare metriche di bias e un template di model card. Allegare una licenza libera e pubblicare il risultato in un repository dedicato consente ad altri di verificare, migliorare e riutilizzare; con il tempo, la comunità costruisce standard de facto che rendono l’audit più semplice, comparabile e utile anche per chi sviluppa.
