Scenario illustrativo: persone e organizzazioni sono ipotetiche. Non è un incarico o un risultato attribuito allo studio.
LA RISPOSTA IN BREVE
Il fatto che lo scambio avvenga attraverso una libreria tecnica non lo rende estraneo alle responsabilità del progetto. Vanno verificati dati inviati, destinatari, finalità e basi applicabili, oltre alle eventuali regole sull’accesso al dispositivo.
La situazione.
Scenario illustrativo fittizio. Una società commissiona un’app per prenotare servizi. Lo sviluppatore inserisce un SDK gratuito per misurare errori e utilizzo. Durante una verifica emerge l’invio di identificativi del dispositivo e dettagli delle schermate a un soggetto terzo. Il committente pensava che il componente producesse soltanto statistiche aggregate sul proprio server.
PRIMA DI DECIDERE
Tre fatti da mettere a fuoco.
- 01
Occorre distinguere i dati raccolti dalla libreria dalle sole statistiche mostrate nella console al committente.
- 02
Il destinatario potrebbe utilizzare i dati per proprie finalità, non necessariamente operare come responsabile.
- 03
L’invio può iniziare all’apertura dell’app, prima che l’utente abbia ricevuto informazioni o espresso una scelta dove richiesta.
Valuta insieme questi elementi prima di scegliere le azioni.
Come impostare la valutazione.
L’analisi privacy deve guardare al comportamento effettivo dell’app. Una dashboard aggregata non dimostra che la raccolta a monte sia anonima: identificativi, eventi e combinazioni di informazioni possono rendere le persone riconoscibili. Il ruolo del terzo dipende dalle finalità e dai mezzi realmente determinati, non dall’espressione «partner tecnico» usata nelle condizioni.
Occorre verificare insieme GDPR e disciplina pertinente alle informazioni nel terminale. Non è corretto presumere che ogni funzione di analisi richieda sempre la stessa base giuridica, né che una finalità tecnica giustifichi automaticamente tutti i dati raccolti. La scelta deve riguardare la configurazione concreta e la necessità di ciascun dato. Il controllo va ripetuto sugli aggiornamenti: librerie e condizioni possono cambiare senza modifiche evidenti nell’interfaccia.
Cosa fare, in pratica.
- 01
Inventariare SDK e servizi contattati dall’app, chiedendo allo sviluppatore documentazione e verifiche di traffico pertinenti senza raccogliere dati reali non necessari al test.
- 02
Confrontare dati effettivamente trasmessi, finalità dichiarate e condizioni del terzo, chiarendo se il rapporto richieda un accordo da responsabile o un diverso assetto.
- 03
Disattivare o limitare raccolte non giustificate, valutando alternative che consentano diagnosi e statistiche con informazioni meno dettagliate e meno identificative.
- 04
Allineare informativa, eventuali consensi e impostazioni al funzionamento effettivo, verificando cosa accada prima della scelta e dopo una revoca.
- 05
Inserire verifiche privacy nel processo di rilascio, in modo che aggiunta e aggiornamento degli SDK richiedano una valutazione del committente e non solo una decisione tecnica.
L’errore da evitare.
Descrivere l’app come priva di condivisioni perché il committente vede soltanto numeri aggregati, senza esaminare il trasferimento verso il fornitore dell’SDK.
Tre verifiche da portare con te.
- SDK e destinatari inventariati.
- Raccolta iniziale distinta dalla visualizzazione aggregata.
- Aggiornamenti sottoposti a controllo dei flussi.
Un componente gratuito può avere un costo in termini di dati. Il responsabile del progetto deve conoscere gli scambi introdotti nel prodotto.
Fonti e riferimenti.
Collegamenti alle fonti istituzionali utilizzate per il quadro di riferimento. Controlla versione, ambito e regole complementari applicabili.