Informativa sulla privacy — directtransfer.ch

0Informazioni su questo documento

La presente è l'Informativa sulla privacy del sito istituzionale directtransfer.ch e delle applicazioni DirectTransfer (passeggero e conducente), gestite da la piattaforma, incluso il modulo Cargo B2B. Descrive quali dati personali trattiamo, per quale finalità, con quale base giuridica, con chi li condividiamo, per quanto tempo li conserviamo e quali sono i vostri diritti ai sensi della Legge federale svizzera sulla protezione dei dati (LPD/nDSG).

Nota di traduzione: gli articoli della Legge federale svizzera sulla protezione dei dati (in inglese *Federal Act on Data Protection*, FADP; in tedesco *Datenschutzgesetz*, DSG/nDSG; in francese *Loi sur la protection des données*, LPD) citati di seguito si basano sul testo consolidato pubblicato dalla Confederazione su Fedlex (RS 235.1), aggiornato al 2025-07-07. Il testo vincolante è sempre quello tedesco, francese o italiano; dove questa informativa utilizza in aggiunta la sigla inglese "FADP", ciò avviene esclusivamente per coerenza con il documento sorgente portoghese di questa informativa.

1Chi siamo e cosa copre questo documento

DirectTransfer è gestita da la piattaforma ("noi", "la piattaforma", "DirectTransfer"), titolare del trattamento di dati personali ai sensi dell'art. 5 al. j LPD/nDSG per le finalità descritte nella presente informativa.

Identità: DirectTransfer, una piattaforma di trasporto con base in Svizzera. Stato di attuazione, con precisione: ragione sociale, sede legale registrata e numero di registrazione commerciale (UID) non sono pubblicati in questa informativa finché non esiste una registrazione ufficiale e verificabile nel registro di commercio svizzero (Zefix/UID) — nessuna attribuzione a una persona giuridica non confermata è fatta in nessun punto di questo documento.
Contatto per questioni di privacy: privacidade@directtransfer.ch.
Autorità di vigilanza competente: Incaricato federale della protezione dei dati e della trasparenza (IFPDT), ai sensi dell'art. 4 LPD/nDSG.

La presente informativa si applica al sito directtransfer.ch, all'applicazione del passeggero, all'applicazione del conducente e al modulo Cargo B2B, ogniqualvolta trattiamo dati personali di un interessato ai sensi dell'art. 5 al. b LPD/nDSG.

1.1Cos'è DirectTransfer, e cosa non è — riaffermazione obbligatoria

Questa clausola viene riaffermata perché condiziona direttamente il modo in cui trattiamo i vostri dati: DirectTransfer è un software come servizio (SaaS). la piattaforma non impiega mai il conducente — non esiste alcun rapporto di lavoro subordinato; il conducente è responsabile del proprio veicolo, dell'assicurazione e dell'orario. La piattaforma non fissa mai il prezzo della corsa — il conducente determina l'importo entro una fascia meramente suggerita, nell'ambito di un meccanismo di asta/negoziazione bilaterale. La piattaforma non intermedia mai finanziariamente la corsa — il pagamento della corsa avviene al cento per cento tra pari (P2P) tra passeggero e conducente, tramite TWINT, SumUp, contanti o carta propria del conducente; nessun dato di pagamento della corsa è trattato o conservato da DirectTransfer. Ciò è distinto e separato dal pagamento dell'abbonamento mensile del conducente alla piattaforma (sezione 4.9), che costituisce un flusso di dati diverso. Questa distinzione determina, tra le altre cose, quali dati di pagamento esistono nel nostro sistema e quali non esisteranno mai.

2Definizioni rilevanti (art. 5 LPD/nDSG)

Utilizziamo i termini della legge come definiti dal suo art. 5:

Dati personali: tutte le informazioni concernenti una persona fisica identificata o identificabile (art. 5 al. a).
Interessato: la persona fisica i cui dati personali sono oggetto di trattamento (art. 5 al. b).
Dati personali degni di particolare protezione: comprendono, tra l'altro, i dati biometrici che identificano in modo univoco una persona fisica, nonché i dati relativi a procedimenti o sanzioni amministrativi e penali (art. 5 al. c, n. 4 e 5). Nota applicata al nostro caso concreto: il documento d'identità e la patente di guida presentati dal conducente in fase di registrazione, e il dato biometrico da essi estratto dal fornitore terzo di verifica dell'identità (KYC/IDV), costituiscono dati personali degni di particolare protezione ai sensi del n. 4 — non sono trattati come dati personali comuni, vedere sezione 7. L'estratto del casellario giudiziale del conducente, richiesto in alcuni cantoni, costituisce un dato personale degno di particolare protezione ai sensi del n. 5 (dati relativi a procedimenti o sanzioni amministrativi e penali) — vedere sezioni 4.2 e 6.
Trattamento: qualsiasi operazione relativa a dati personali — raccolta, registrazione, conservazione, utilizzo, modifica, comunicazione, archiviazione, cancellazione o distruzione (art. 5 al. d).
Violazione della sicurezza dei dati: perdita, cancellazione, distruzione, modifica di dati personali oppure accesso o comunicazione non autorizzati, accidentali o illeciti agli stessi (art. 5 al. h).
Titolare del trattamento: chi decide, da solo o congiuntamente con altri, sullo scopo e sui mezzi del trattamento — la piattaforma, per le finalità qui descritte (art. 5 al. j).
Responsabile del trattamento (per conto del titolare): chi tratta dati personali per conto del titolare — ad esempio, il fornitore dell'infrastruttura di archiviazione delle immagini, o il fornitore della verifica documentale (art. 5 al. k).

3Principi che applichiamo (art. 6 LPD/nDSG)

Ogni trattamento descritto nella presente informativa segue i principi dell'art. 6 LPD/nDSG: liceità (§1); trattamento secondo buona fede e proporzionalità (§2); raccolta solo per uno scopo determinato e riconoscibile dall'interessato, senza ulteriore trattamento incompatibile con tale scopo (§3); distruzione o anonimizzazione dei dati non appena non più necessari allo scopo del trattamento (§4); esattezza dei dati, con rettifica o cancellazione di quanto inesatto o incompleto (§5). Laddove richiediamo il vostro consenso, questo è valido solo se prestato liberamente, per uno o più trattamenti determinati, sulla base di un'informazione adeguata (§6); ed è espressamente richiesto per il trattamento di dati personali degni di particolare protezione (§7 al. a).

Nota metodologica sulla citazione della base giuridica in questa informativa: la LPD/nDSG non prevede un elenco enumerato di "basi giuridiche" sul modello dell'art. 6(1) del RGPD. Il regime svizzero è il seguente: il trattamento è lecito se rispetta i principi di questo art. 6 (liceità, proporzionalità, finalità) e non lede i diritti della personalità dell'interessato (art. 30); qualora sussista una potenziale lesione della personalità, il trattamento richiede un proprio motivo giustificativo ai sensi dell'art. 31, tipicamente la "conclusione o l'esecuzione di un contratto" ai sensi dell'art. 31 §2 al. a (vedere applicazione diretta alla sezione 13). Per questo motivo, ogni sottosezione della sezione 4 seguente ancora la liceità generale all'art. 6 e invoca l'art. 31 §2 al. a solo laddove esista un'effettiva giustificazione di una potenziale incidenza sulla personalità derivante dall'esecuzione di un contratto; da questa sezione in poi, ogni sottosezione che invochi questo motivo lo fa con un rinvio breve ("motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito nella presente sezione 3"), senza ripetere il paragrafo esplicativo completo. Gli art. 16-17 LPD/nDSG riguardano esclusivamente il trasferimento internazionale di dati (comunicazione di dati personali all'estero) e sono citati solo alla sezione 8, mai come base giuridica generale per il trattamento interno.

Nota di traduzione su "motivo giustificativo": il documento sorgente portoghese utilizza il termine "fundamento de justificação", concetto proprio del regime LPD/nDSG ai sensi dell'art. 31, privo di equivalente diretto nel vocabolario del RGPD. Il termine "motivo giustificativo" (art. 31) è qui impiegato deliberatamente come termine tecnico-giuridico della versione italiana della LPD/nDSG, e non deve essere assimilato al concetto di "base giuridica" del RGPD, che porta con sé una connotazione diversa, come spiegato in questa sezione.

Nota di verifica della fonte, riguardo "art. 31 §2 al. a": l'esistenza del motivo giustificativo dell'esecuzione del contratto nell'art. 31 §2 è confermata dalla fonte primaria consultata (il registro delle fonti primarie della LPD/nDSG tenuto internamente per questa informativa, Parte A, "Art. 30-31"), ma tale fonte riassume/parafrasa il contenuto dell'articolo — a differenza degli art. 5, 6, 8, 19 e 25, che sono copie letterali (verbatim) estratte tramite pdftotext dal PDF ufficiale Fedlex — senza citare il testo integrale e numerato delle lettere dell'art. 31 §2. Il riferimento alla lettera esatta "al. a" in questa informativa è quindi la lettura più probabile, coerente con la struttura tipica di questo genere di norma, non una citazione verificata testualmente della lettera. La sostanza del motivo (esecuzione del contratto come motivo giustificativo di una potenziale incidenza sulla personalità) è utilizzata in questa informativa con un livello di affidabilità elevato; la formulazione esatta della lettera resta a un livello di affidabilità medio, soggetta a conferma diretta rispetto al testo integrale dell'art. 31 o al parere di un avvocato svizzero abilitato — lo stesso standard di cautela già applicato all'art. 9 (vedere il registro giuridico interno dettagliato tenuto a tale scopo).

4Quali dati raccogliamo e a quale scopo

4.1Registrazione dell'account

Nome, recapiti (telefono, e-mail) del passeggero e del conducente, al momento della creazione dell'account. Finalità: fornire il servizio di intermediazione tecnologica tra passeggero e conducente. Base giuridica: liceità, proporzionalità e finalità riconoscibile del trattamento (art. 6 §1-3) — i dati sono raccolti per lo scopo specifico e riconoscibile dall'interessato di creare e gestire l'account; motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3.

4.2Verifica documentale del conducente — dati sensibili

In fase di registrazione del conducente, raccogliamo documento d'identità, patente di guida e, a seconda del cantone e della categoria, altre autorizzazioni (ad es. carte de taxi, carte de limousine — tessere amministrative cantonali per taxi e limousine). Laddove richiesto dal cantone — ad esempio Zurigo e Basilea, secondo una ricerca regolamentare cantonale interna già disponibile per il progetto — raccogliamo anche l'estratto del casellario giudiziale del conducente, con validità inferiore a 3 mesi al momento della presentazione. Questi documenti sono presentati tramite fotografia, secondo il flusso descritto nel modulo di Registrazione del conducente, e trattati su due livelli:

Livello 1 — fornitore terzo (KYC/IDV): conferma l'autenticità del documento ed estrae i campi leggibili (nome, numero, date, tipo di documento), inclusa, ove applicabile, la verifica biometrica. Questo trattamento riguarda dati personali degni di particolare protezione ai sensi dell'art. 5 al. c n. 4 (documento d'identità, patente di guida, dati biometrici) e, ove applicabile all'estratto del casellario giudiziale, n. 5 (dati relativi a procedimenti o sanzioni amministrativi e penali) — con conseguente necessità del vostro consenso esplicito (art. 6 §7 al. a) al momento della presentazione del documento, nonché di un contratto di trattamento dati con il fornitore. Questo obbligo deriva dal trattamento di dati personali da parte di un responsabile del trattamento per conto del titolare — l'art. 5 al. k LPD/nDSG definisce il responsabile del trattamento in questi termini — ed è inquadrato nei principi generali di liceità e proporzionalità dell'art. 6 e nell'obbligo di sicurezza dell'art. 8. La presente informativa non cita qui un numero di articolo specifico della LPD/nDSG relativo al sub-trattamento oltre alla definizione dell'art. 5 al. k, poiché ciò non è stato confermato rispetto al testo integrale della legge.
Livello 2 — motore di regole interno, senza intelligenza artificiale: verifica se i campi estratti soddisfano il requisito documentale del cantone e della categoria dichiarati. Non utilizza alcun modello di IA/ML; si tratta di un confronto deterministico rispetto a una tabella di configurazione.

Un esito incerto su uno dei due livelli non viene mai approvato né respinto automaticamente — passa sempre alla revisione umana di un amministratore. I documenti del conducente, incluso l'estratto del casellario giudiziale, sono accessibili solo al conducente stesso e agli amministratori, mai al passeggero, con lo stesso trattamento rafforzato (consenso esplicito, RBAC ristretto) descritto alla sezione 6.

Rinnovo e verifica continuativa: il requisito minimo applicato è la validità inferiore a 3 mesi dell'estratto del casellario giudiziale al momento di ciascuna presentazione; la presentazione iniziale non deve essere intesa come copertura per l'intero ciclo di vita del conducente. La frequenza di rinnovo richiesta e il meccanismo di verifica continuativa dei precedenti, ove applicabile a seconda del cantone, sono comunicati direttamente al conducente tramite il canale di contatto dell'app, e saranno pubblicati in questa sezione non appena sarà finalizzata la relativa politica operativa.

Fornitore terzo (KYC/IDV): il nome commerciale del fornitore sarà pubblicato in questa sezione non appena sarà finalizzata la selezione, secondo il processo di gara in corso; nel frattempo disponibile su richiesta tramite il canale di contatto della sezione 15. Il contratto di trattamento dati con tale fornitore, sopra menzionato, e la valutazione del trasferimento internazionale (sezione 8), qualora il fornitore non operi in territorio svizzero o UE/SEE, saranno conclusi e pubblicati insieme a tale identificazione, prima che qualsiasi presentazione di documenti venga trattata da tale fornitore in produzione.

4.3Localizzazione in tempo reale durante la corsa

La posizione approssimativa dei veicoli disponibili è condivisa con il passeggero prima dell'accettazione di una corsa; dopo l'accettazione, la posizione del conducente è condivisa con il passeggero fino all'imbarco. Finalità: esecuzione diretta del contratto di trasporto concordato tra passeggero e conducente. Base giuridica: proporzionalità e finalità riconoscibile dall'interessato al momento della richiesta (art. 6 §2-3), potendo incidere sulla personalità dell'interessato attraverso l'esposizione della posizione geografica a un terzo; motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3.

4.4Foto del luogo di prelievo — cancellazione automatica entro 24 ore

Durante la comunicazione della corsa, può essere condivisa tra passeggero e conducente una foto del luogo di prelievo, archiviata su Cloudflare R2.

Il disegno del ciclo di vita già congelato del progetto prevede la cancellazione automatica di questa foto 24 ore dopo il caricamento, e nessuna conservazione oltre tale termine per alcuna finalità secondaria — secondo il disegno interno dello schema dati del progetto, che fissa questa finestra di 24 ore come derivata al momento della query (created_at + interval '24 hours') per i messaggi di tipo photo. Stato di attuazione, con precisione: il servizio backend della piattaforma esiste ed è operativo per la registrazione del conducente, ma il modulo corsa/chat che eseguirebbe questa finestra — un job applicativo di espurgo e/o una regola di ciclo di vita del bucket Cloudflare R2 — non è ancora stato costruito; e, per quanto riguarda il livello del database, la ratifica finale della relativa policy di sicurezza a livello di database da parte della revisione di sicurezza interna di la piattaforma resta ancora in sospeso. Finché tale modulo non sarà costruito e tale ratifica non sarà completata, le 24 ore qui descritte costituiscono il disegno vincolante del progetto, non ancora un fatto operativo verificabile in produzione.

Finalità: agevolare l'incontro fisico tra le parti. Base giuridica: esecuzione del contratto e proporzionalità (art. 6 §2-3); la cancellazione automatica entro 24 ore progettata sopra è l'applicazione concreta dell'obbligo di distruzione dell'art. 6 §4 non appena il dato non è più necessario alla finalità — l'incontro è già avvenuto; motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3.

4.5Messaggi della chat di corsa (`ride_messages`)

Durante una corsa attiva, passeggero e conducente possono scambiarsi messaggi predefiniti, testo libero limitato (fino a 100 caratteri) o una foto, tramite la chat della corsa. Finalità: comunicazione diretta tra le parti durante la corsa attiva — ad esempio istruzioni di imbarco, adeguamento del punto d'incontro — mentre la corsa è in corso.

Conservazione: la regola di ciclo di vita progettata è la cancellazione effettiva (hard delete) del contenuto della chat alla chiusura della corsa — decisione di disegno già chiusa del progetto quanto al criterio, non una lacuna. Secondo la revisione di sicurezza e conformità interna di la piattaforma, si tratta dell'applicazione diretta del comandamento "Zero chat dopo la conclusione della corsa", e questa regola è registrata esplicitamente nel disegno interno dello schema dati del progetto. Stato di attuazione, con precisione: questo disegno di schema assegna espressamente il job di espurgo al servizio backend della piattaforma; tale servizio backend esiste ormai ed è operativo per la registrazione del conducente, ma il modulo corsa/chat che eseguirebbe questo specifico job di espurgo non è ancora stato costruito; la relativa policy di sicurezza a livello di database resta registrata soltanto come bozza interna, esplicitamente contrassegnata come "STUB, NON RATIFICATO", in attesa di ratifica finale da parte della revisione di sicurezza interna di la piattaforma. Finché tale modulo non sarà costruito e tale ratifica non sarà completata, la rimozione effettiva (hard delete, non un soft-delete, senza marcatura "eliminato") costituisce il disegno vincolante del progetto, non ancora un fatto operativo verificabile in produzione.

Base giuridica: esecuzione del contratto di trasporto tra le parti e sicurezza del coordinamento della corsa in corso (art. 6 §2-3); la cancellazione automatica alla chiusura della corsa, progettata sopra, è l'applicazione concreta dell'obbligo di distruzione dell'art. 6 §4 non appena il dato non è più necessario alla finalità — la corsa è già terminata; motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3.

Nessun messaggio di chat viene letto, moderato o conservato da DirectTransfer oltre quanto necessario al funzionamento tecnico in tempo reale della corsa stessa; qualsiasi lettura puntuale da parte di un amministratore nell'ambito dell'istruttoria di una segnalazione formale segue lo stesso schema di accesso privilegiato sottoposto ad audit descritto alla sezione 12.

Metadati di segnalazione di abuso — in valutazione, non implementati: è in valutazione una registrazione minima di metadati di segnalazione di abuso (non il contenuto del messaggio), subordinata a una citazione giuridica prima di qualsiasi implementazione, secondo la revisione di sicurezza e conformità interna di la piattaforma; in caso di implementazione, questa sezione sarà aggiornata.

4.6Comunicazione tramite chiamata telefonica — chiamata GSM nativa, senza VoIP

La piattaforma mette a disposizione un pulsante di chiamata che utilizza la funzione di chiamata GSM nativa del telefono cellulare di ciascun utente. Non esiste alcun sistema VoIP, WebRTC o intermediazione della chiamata da parte di DirectTransfer — la chiamata transita interamente attraverso la rete dell'operatore mobile di ciascuna parte, al di fuori della nostra infrastruttura.

Informativa rilevante per il vostro consenso informato: utilizzando questo pulsante, il numero di telefono di ciascuna parte può diventare visibile all'altra parte al momento della chiamata, poiché la rete GSM nativa trasmette il numero reale di origine/destinazione a entrambe le parti per la natura stessa del protocollo — questa esposizione non può essere evitata mantenendo il pulsante di chiamata nativo, secondo la valutazione tecnica registrata dalla revisione di sicurezza e conformità interna di la piattaforma.

Cosa non esiste: nessun numero proxy di rete sostituisce il vostro numero reale durante la chiamata — non esiste un vero proxy/relay telefonico; tra le altre ragioni, un relay di questo tipo entrerebbe in collisione con il veto "Zero VoIP" già fissato per questo prodotto.

Cosa esiste: l'app non mostra mai il vostro numero, né quello dell'altra parte, come testo su alcuna schermata delle app passenger o driver — il numero compare esclusivamente come pulsante d'azione; e l'app richiede conferma esplicita prima di attivare il compositore nativo (un avviso che il numero diventerà visibile all'altra parte proseguendo). Queste due mitigazioni sono comportamento predefinito nelle app.

Nota sulla soppressione dell'identificazione del chiamante (CLIR): ove disponibile, la soppressione del numero di origine tramite un codice di rete nativo (ad es. prefisso #31#/*31#) dipende interamente dall'operatore telefonico di ciascun utente — la piattaforma non verifica, non impone né garantisce questa soppressione prima di attivare il compositore nativo. Non si tratta di una mitigazione garantita dal prodotto; è registrata come elemento di indagine di fattibilità per operatore, non ancora conclusa, secondo la revisione di sicurezza e conformità interna di la piattaforma.

Nota secondaria: il mascheramento dello schermo sopra descritto non copre il back-office admin, che dispone già di accesso in lettura in chiaro al numero di telefono tramite RBAC sulla tabella users (sezioni 6 e 12), a fini di supporto — questo accesso privilegiato genera obbligatoriamente un registro di audit (chi, quando, perché); non costituisce un'eccezione silenziosa alla mitigazione dello schermo.

Non registriamo, non conserviamo e non abbiamo accesso ad alcun contenuto di tale chiamata, poiché essa non transita mai attraverso la nostra infrastruttura.

Base giuridica: l'obbligo di informazione e trasparenza ai sensi dell'art. 19 §2 al. c LPD/nDSG, che richiede di informare l'interessato, al momento della raccolta dei dati, sui "destinatari o le categorie di destinatari a cui i dati personali sono comunicati" (testo letterale, secondo il registro delle fonti primarie tenuto internamente per questa informativa, Parte A) — questo è l'inquadramento specifico corretto per questo scenario, individuato dalla revisione di sicurezza e conformità interna di la piattaforma: l'altra parte della corsa è la destinataria a cui il numero di telefono diventa visibile al momento della chiamata, il che costituisce precisamente una comunicazione a un destinatario, non l'estensione generica del §1 dello stesso articolo (informare su dati non raccolti presso l'interessato stesso) utilizzata in una versione precedente di questo testo; tale esposizione è comunicata in anticipo da questa clausola — nonché la proporzionalità del trattamento (art. 6 §2), alla finalità di rendere possibile l'incontro fisico e la comunicazione durante la corsa. Motivo giustificativo della comunicazione stessa: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3 — questo motivo non è toccato dal riancoraggio sopra, che riguarda solo la componente dell'obbligo di informazione/trasparenza. Questo obbligo informativo è adempiuto tramite l'informativa esplicita sopra riportata e il dialogo di conferma obbligatorio prima dell'attivazione del compositore nativo. Questa è la base giuridica presentata da questa informativa per questa clausola — vedere lo stato di conferma nel paragrafo seguente.

Stato di attuazione, con la stessa disciplina di precisione utilizzata in tutta questa informativa: il comportamento sopra descritto (mascheramento dello schermo, dialogo di conferma) è il disegno vincolante già congelato del progetto per le app passenger e driver. Il blocco dell'attivazione di questo flusso in produzione, secondo la revisione di sicurezza e conformità interna di la piattaforma, non dipende dal servizio backend della piattaforma (questo flusso, a differenza di quelli delle sezioni 4.4, 4.5, 4.7, 6 e 12, non transita mai attraverso la nostra infrastruttura, come sopra descritto) — dipende dalla conferma della sufficienza giuridica da parte della revisione di sicurezza e conformità interna di la piattaforma circa il fatto che l'inquadramento di cui sopra, art. 19 §2 al. c + art. 6 §2, copra adeguatamente, in termini di proporzionalità, questo scenario specifico. Il riancoraggio della citazione all'art. 19 §2 al. c, applicato sopra, corregge l'inquadramento precedentemente descritto come incerto in questa informativa: l'esposizione del numero di telefono di una parte all'altra parte durante la chiamata è una comunicazione a un destinatario al momento della chiamata, ed è esattamente questo scenario — l'obbligo di informare sui "destinatari... a cui i dati personali sono comunicati" — che l'art. 19 §2 al. c copre nel suo testo letterale, non più l'estensione generica del §1 (informare su dati non raccolti presso l'interessato stesso) utilizzata in una versione precedente di questo testo. Questa informativa presenta l'art. 19 §2 al. c + art. 6 §2 come base per la comunicazione già effettuata sopra; la sufficienza di tale inquadramento rispetto al test di proporzionalità dell'art. 6 §2 in questo scenario concreto — ad esempio, se l'assenza di un'opzione di rifiuto della funzionalità o di una garanzia CLIR incida su tale sufficienza — rimane una conferma tecnico-giuridica della revisione di sicurezza e conformità interna di la piattaforma, non un fatto già definito dal solo team legale interno. Nota di coordinamento tra documenti: questa posizione è quella della presente Informativa sulla privacy in particolare; la clausola parallela sullo stesso tema nei Termini di utilizzo segue il proprio ciclo di aggiornamento e resta contrassegnata in quel documento come in attesa di citazione — i due documenti non convergono ancora, e questa nota evita l'apparenza che convergano già.

4.7Cronologia delle corse e identificativo anonimizzato (modello a due fasi)

Per ogni corsa, registriamo: origine e destinazione (coordinate e indirizzo testuale), timestamp di inizio e fine, categoria del veicolo, valore dichiarato dal conducente, stato finale della corsa, e un identificativo del passeggero e del conducente. Nessun altro dato è registrato per impostazione predefinita.

Questo identificativo funziona in due fasi distinte, non in un'unica fase:

1. Durante la corsa attiva: l'identificativo è risolvibile (riferimento diretto al record dell'utente), necessario per le funzionalità in tempo reale — controllo di accesso a livello di riga (RLS), connessione in tempo reale (Socket.io) e chat della corsa in corso (sezione 4.5).

2. Nel passaggio alla cronologia, al termine della corsa, l'identificativo viene convertito in un hash crittografico irreversibile e salato (ad es. SHA-256), senza chiave esterna che consenta di risalire all'identità dell'utente a partire dal record storico.

La regola predefinita così progettata, secondo il Comandamento 5 (Row Level Security) e i requisiti RLS già specificati dalla revisione di sicurezza e conformità interna di la piattaforma, è la non identificazione nominale reciproca tra le parti: né il passeggero deve vedere il nome del conducente, né il conducente il nome del passeggero, su alcuna schermata, inclusa la cronologia. Stato di attuazione, con precisione: questa regola è progettata e riflessa nel modello a due fasi sopra descritto (identificativo risolvibile durante la corsa, hash irreversibile nel passaggio alla cronologia), ma il meccanismo eseguibile di applicazione — policy di sicurezza concrete a livello di database e il livello di mascheramento delle colonne che impedisce la fuga di identità anche quando la riga è visibile — dipende dalla ratifica tecnica finale da parte della revisione di sicurezza interna di la piattaforma e dal modulo corsa/cronologia del servizio backend della piattaforma, che non è ancora stato costruito (il servizio backend copre oggi solo la registrazione del conducente); la relativa policy di sicurezza a livello di database resta contrassegnata "STUB, NON RATIFICATO" nella bozza interna. Questa sezione non afferma la non identificazione nominale come un fatto operativo già attivo in produzione, ma solo come regola di disegno già congelata, in attesa di applicazione tecnica ratificata.

Identificazione per motivi di sicurezza — in valutazione, non decisa: è ancora in valutazione se, per motivi di sicurezza, possa rendersi necessaria un'identificazione puntuale tra conducente e passeggero (o viceversa), il che creerebbe una tensione con la regola generale di non identificazione nominale già congelata sopra — secondo la documentazione di prodotto interna del progetto relativa alla cronologia delle corse. Questa informativa non afferma, in questa versione, né l'identificazione né la sua totale assenza come eccezione di sicurezza — afferma solo la regola generale di non identificazione reciproca già congelata, applicabile finché questa valutazione non sarà conclusa. Qualsiasi futura risoluzione di questo punto è registrata in questa sezione e confermata dalla revisione di sicurezza interna di la piattaforma come compatibile, o meno, con la RLS già congelata, senza riapertura informale.

Base giuridica dell'anonimizzazione: il passaggio alla cronologia è l'applicazione diretta dell'obbligo di cui all'art. 6 §4 — il dato viene anonimizzato non appena non più necessario, in forma identificabile, alla finalità di gestione della corsa in corso.

4.8Valutazione della piattaforma (da 0 a 5 stelle)

Al termine di ogni corsa, il passeggero può valutare la piattaforma, non il singolo conducente. Questa valutazione è collegata all'identificativo anonimizzato del passeggero e all'evento di corsa, a fini di metrica di prodotto dell'azienda. Non viene mai aggregata, mostrata o consultabile per identificativo del conducente, non compare mai su alcuna schermata o API accessibile al conducente, e non è mai utilizzata per assegnare una corsa. Base giuridica: interesse legittimo e proporzionato a misurare la soddisfazione per il servizio fornito dalla piattaforma (art. 6 §2), senza alcuna finalità di gestione o valutazione della prestazione individuale del conducente — questa distinzione di finalità è precisamente la ragione per cui questa valutazione non viene resa nota al conducente.

4.9Pagamenti — corsa (P2P) e abbonamento (Stripe), flussi separati

Con riferimento al rinvio della sezione 1.1: il pagamento della corsa avviene al cento per cento tra pari, al di fuori della nostra infrastruttura, e non trattiamo né conserviamo alcun dato di pagamento della corsa. L'unico flusso di pagamento che trattiamo è l'abbonamento mensile del conducente alla piattaforma, tramite il fornitore di servizi di pagamento Stripe (Stripe Billing), che tratta direttamente i dati di fatturazione e della carta del conducente, secondo le condizioni e l'informativa sulla privacy proprie di Stripe. Base giuridica: proporzionalità e finalità del trattamento (art. 6 §2-3), esecuzione del contratto di abbonamento tra il conducente e la piattaforma; motivo giustificativo: art. 31 §2 al. a, secondo il criterio già stabilito alla sezione 3.

4.10Modulo Cargo B2B e flussi potenzialmente transfrontalieri

Il modulo Cargo B2B può coinvolgere clienti e vettori situati nell'Unione europea. Vedere la sezione 10 sul regime giuridico applicabile a questo caso.

4.11Sito istituzionale, cookie e analytics

L'inventario finale dei cookie e delle tecnologie di tracciamento del sito istituzionale directtransfer.ch sarà pubblicato in questa sezione, con rinvio a una politica sui cookie dedicata qualora la complessità lo giustifichi, prima dell'attivazione di qualsiasi cookie non strettamente necessario al funzionamento tecnico del sito. Fino a tale pubblicazione, il sito istituzionale non attiva alcun cookie di analytics o di marketing di terzi senza che tale inventario sia prima descritto qui e, ove applicabile, senza il consenso preventivo richiesto dall'art. 6 §6-7 LPD/nDSG.

4.12Sicurezza, prevenzione delle frodi e conformità legale

Possiamo trattare dati personali per individuare e prevenire frodi, e per adempiere a un obbligo legale o rispondere a una richiesta legittima di un'autorità competente. Base giuridica: liceità e proporzionalità del trattamento (art. 6 §1-2), inquadrate nell'adempimento di un obbligo legale a cui la piattaforma è soggetta. Laddove questo trattamento costituisca una potenziale incidenza sulla personalità dell'interessato, il motivo giustificativo applicabile deriva dall'art. 31 §2, nelle sue lettere relative all'adempimento di un obbligo legale o alla salvaguardia di un interesse preponderante — categorie generali della norma, distinte dalla al. a (esecuzione del contratto) utilizzata in altre sottosezioni di questa informativa; la lettera esatta applicabile a ciascuna situazione concreta è individuata caso per caso al momento del trattamento.

5Base giuridica, in sintesi

Trattiamo i vostri dati personali sulla base, a seconda dei casi, di: il vostro consenso esplicito, richiesto in particolare per i dati sensibili (art. 6 §6-7 al. a); l'esecuzione del contratto di utilizzo della piattaforma o del contratto di trasporto tra voi e l'altra parte della corsa, con motivo giustificativo ai sensi dell'art. 31 §2 al. a laddove sussista una potenziale incidenza sulla personalità; l'adempimento di un obbligo legale a cui la piattaforma è soggetta; e l'interesse legittimo, sempre soggetto al test di proporzionalità dell'art. 6 §2. Laddove una finalità specifica richieda un consenso esplicito aggiuntivo (ad es. dati sensibili del documento del conducente, sezione 4.2), richiediamo tale consenso separatamente, con registrazione di audit ai sensi della sezione 16.

6Dati personali degni di particolare protezione — trattamento rafforzato

Riprendendo la sezione 4.2: il documento d'identità, la patente di guida e il relativo dato biometrico del conducente sono dati personali degni di particolare protezione (art. 5 al. c n. 4). L'estratto del casellario giudiziale del conducente, richiesto in alcuni cantoni — ad esempio Zurigo e Basilea, secondo una ricerca regolamentare cantonale interna già disponibile per il progetto — è parimenti un dato personale degno di particolare protezione, rientrante nel n. 5 dello stesso articolo (dati relativi a procedimenti o sanzioni amministrativi e penali), e riceve lo stesso trattamento rafforzato di seguito. Applichiamo, a entrambe le categorie, secondo il disegno già congelato del progetto: (i) consenso esplicito al momento della presentazione (art. 6 §7 al. a); (ii) accesso ristretto progettato tramite controllo di accesso basato sui ruoli (RBAC) — solo il conducente stesso e gli amministratori, mai il passeggero, incluso l'estratto del casellario giudiziale, secondo la matrice RBAC già specificata dalla revisione di sicurezza e conformità interna di la piattaforma — il controllo RBAC in sé è costruito, testato e operativo nel servizio backend della piattaforma per l'accesso ai documenti del conducente; la sicurezza a livello di riga del database (RLS) sui dati sottostanti, quale seconda e complementare livello di applicazione descritto alla sezione 4.7 sopra, resta in attesa di ratifica finale da parte della revisione di sicurezza interna di la piattaforma ed è tuttora contrassegnata "STUB, NON RATIFICATO" nella bozza interna; (iii) delega dell'autenticità e dell'estrazione del documento a un fornitore terzo affermato, sotto contratto di trattamento dati — obbligo derivante dal trattamento di dati personali da parte di un responsabile del trattamento per conto del titolare (art. 5 al. k LPD/nDSG), inquadrato nei principi generali degli art. 6 e 8, senza citare qui un numero di articolo relativo al sub-trattamento oltre a tale definizione, poiché ciò non è stato confermato rispetto al testo integrale della legge; (iv) nessun motore di riconoscimento facciale biometrico sviluppato internamente da la piattaforma.

7Con chi condividiamo i dati

Condividiamo dati personali, nella misura necessaria a ciascuna finalità descritta alla sezione 4, con:

Fornitore terzo di verifica dell'identità e dei documenti (KYC/IDV), per la verifica documentale del conducente, incluso l'estratto del casellario giudiziale ove applicabile (sezione 4.2). Nome commerciale pubblicato in questa sezione non appena finalizzata la selezione; nel frattempo disponibile su richiesta tramite il canale di contatto della sezione 15.
Stripe, per il trattamento dell'abbonamento mensile del conducente (sezione 4.9) — mai per il pagamento della corsa.
Cloudflare, quale fornitore dell'infrastruttura di archiviazione (R2) per la foto del luogo di prelievo (sezione 4.4).
L'autorità cantonale competente, quando richiesto per convalidare l'autorizzazione di trasporto del conducente, o per obbligo legale.
L'autorità di vigilanza (IFPDT) o altra autorità competente, quando richiesto dalla legge.

Non vendiamo dati personali a terzi. Non condividiamo dati di corsa identificabili a fini pubblicitari di terzi.

8Trasferimento internazionale di dati (art. 16-17 LPD/nDSG)

Qualsiasi responsabile del trattamento situato al di fuori della Svizzera che produce un effetto su un utente in Svizzera è soggetto alla LPD/nDSG in virtù del suo ambito di applicazione territoriale (art. 3 §1). Qualora un nostro fornitore (ad esempio il fornitore KYC/IDV, o Stripe, a seconda della giurisdizione di trattamento) sia stabilito al di fuori della Svizzera e in assenza di una decisione di adeguatezza del Consiglio federale (art. 16 §1), il trasferimento si fonda su una delle basi dell'art. 16 §2: clausole standard approvate dall'IFPDT (al. d), clausole contrattuali di protezione dei dati previamente notificate alla medesima autorità (al. b), o un'altra base equivalente della norma; in alternativa, sulle eccezioni dell'art. 17 §1, in particolare il consenso esplicito (al. a) o il collegamento diretto con un contratto (al. b).

Nota di verifica della fonte, sulle lettere citate dell'art. 16 §2 e dell'art. 17 §1 sopra: come già indicato alla sezione 3 riguardo all'art. 31 §2 al. a, il registro delle fonti primarie tenuto internamente per questa informativa (Parte A, "Art. 16-17") presenta queste lettere tramite riassunto/parafrasi del compilatore — "verbatim, riassunto alle lettere operative", nel testo stesso della fonte — e non tramite trascrizione letterale e numerata del testo integrale dei due articoli, a differenza degli art. 5, 6, 8, 19 e 25, citati in questa informativa da copia letterale estratta tramite pdftotext dal PDF ufficiale Fedlex. L'esistenza dei quattro meccanismi sopra citati (clausole standard approvate dall'IFPDT, clausole contrattuali previamente notificate alla medesima autorità, consenso esplicito, collegamento diretto con un contratto) è utilizzata in questa informativa con un livello di affidabilità elevato; la formulazione esatta di ciascuna lettera (al. b e al. d dell'art. 16 §2; al. a e al. b dell'art. 17 §1) resta a un livello di affidabilità medio, soggetta a conferma diretta rispetto al testo integrale dell'art. 16 e dell'art. 17 su Fedlex o al parere di un avvocato svizzero abilitato — lo stesso standard di cautela già applicato all'art. 31 §2 al. a (sezione 3) e all'art. 9 (vedere il registro giuridico interno dettagliato tenuto a tale scopo).

La base specifica di cui agli art. 16/17 applicabile a ciascun fornitore concreto — KYC/IDV, Stripe, a seconda della giurisdizione di trattamento effettiva — è determinata e pubblicata in questa sezione, per fornitore, prima dell'inizio di qualsiasi trasferimento di dati personali verso tale fornitore. Nessun trasferimento internazionale di dati personali ha luogo senza che la base dell'art. 16 §2 o l'eccezione dell'art. 17 §1 applicabile sia qui individuata e registrata.

9Conservazione dei dati — criterio, ai sensi dell'art. 25 §2 al. d LPD/nDSG

Ai sensi dell'art. 6 §4 LPD/nDSG, distruggiamo o anonimizziamo i dati personali non appena non più necessari alla finalità del trattamento. L'art. 25 §2 al. d LPD/nDSG richiede che informiamo l'interessato "sulla durata di conservazione... o, se ciò non è possibile, sui criteri per determinare tale durata" — la legge accetta espressamente il criterio come alternativa valida a un termine fisso, e questa è la posizione di questa informativa.

Criterio applicato, per categoria di dati:

Dati di corsa identificabili: necessari durante il ciclo di vita operativo della corsa (sezione 4.7, fase 1); al termine della corsa, il dato transita verso una cronologia anonimizzata tramite hash irreversibile (sezione 4.7, fase 2) — da quel momento, non esiste più in forma identificabile.
Foto del luogo di prelievo: disegno di cancellazione automatica 24 ore dopo il caricamento (sezione 4.4) — meccanismo eseguibile in attesa della costruzione del modulo corsa/chat e della ratifica RLS, secondo la nota di tale sezione.
Messaggi della chat di corsa: cancellazione effettiva (hard delete) alla chiusura della corsa — criterio già deciso, meccanismo eseguibile in attesa secondo la nota della sezione 4.5.
Documento del conducente: conservato finché l'autorizzazione di trasporto rimane attiva — questa componente è il disegno già congelato, applicabile da subito. Stato di attuazione, con precisione: questa informativa propone inoltre un termine di conservazione post-disattivazione derivato da un obbligo legale cantonale applicabile al cantone di registrazione del conducente; tale specifico obbligo cantonale non è ancora stato individuato da alcuna fonte primaria del progetto — la stessa sezione 4.2 riconosce già questa lacuna riguardo alla frequenza di rinnovo e alla verifica continuativa dei precedenti. A differenza dei tre criteri precedenti (corsa, foto, chat), che costituiscono un disegno architetturale già congelato e verificabile nello schema, questo quarto criterio rimane parzialmente aperto: "conservato finché l'autorizzazione rimane attiva" si applica da subito; il termine aggiuntivo dovuto a un obbligo legale cantonale potrà essere applicato solo a partire dal momento in cui tale obbligo sarà individuato e citato da una fonte primaria o da un parere legale.

Questa è la posizione di questa informativa in materia di conservazione: un criterio, ai sensi dell'art. 25 §2 al. d, applicato a ciascuna categoria di dati descritta in questa informativa, senza un unico termine numerico per tutte le categorie — poiché nessuna di esse richiede lo stesso termine, e la legge consente espressamente questa forma di risposta. Tre delle quattro categorie sopra indicate (corsa, foto, chat) hanno un criterio interamente definito, ancorato a un disegno architetturale già congelato. La quarta (documento del conducente) ha la propria componente principale — conservazione finché l'autorizzazione rimane attiva — parimenti definita, con la componente aggiuntiva del termine cantonale ancora aperta, secondo la nota specifica su tale punto sopra; questa informativa sarà aggiornata non appena tale obbligo cantonale sarà individuato da una fonte primaria.

10LPD/nDSG e RGPD — duplice informativa

La presente informativa si applica, di norma, ai sensi della Legge federale svizzera sulla protezione dei dati (LPD/nDSG/FADP), applicabile a qualsiasi fattispecie con effetti in Svizzera, anche se avviata all'estero (art. 3 §1).

Il modulo Cargo B2B (sezione 4.10) può coinvolgere clienti o vettori situati nell'Unione europea. Posizione operativa finale di questa informativa: laddove il cliente o il vettore del modulo Cargo sia stabilito nell'Unione europea/Spazio economico europeo, o laddove il trattamento sia volto a offrire un servizio a, o a monitorare il comportamento di, un interessato nell'UE, DirectTransfer applica cumulativamente, a tali flussi specifici, lo standard più protettivo tra la LPD/nDSG e il Regolamento generale sulla protezione dei dati (RGPD/GDPR) — quale politica di conformità preventiva, non quale riconoscimento giuridico definitivo di un'applicabilità stretta del RGPD a DirectTransfer. Ciò include, come minimo, la messa a disposizione dell'interessato dell'UE dei meccanismi di diritto di accesso, portabilità e cancellazione già descritti alla sezione 13, anche laddove la sola LPD/nDSG richiederebbe meno. Un parere legale formale sull'esatto ambito di applicabilità stretta del RGPD a questi flussi sarà ottenuto prima del lancio commerciale transfrontaliero del modulo Cargo; questa informativa sarà aggiornata con la base giuridica RGPD specifica per finalità, inclusa, se necessario, la nomina di un rappresentante nell'UE, non appena tale parere sarà disponibile.

Distinzione necessaria, non ancora valutata: l'eventuale obbligo di nominare un rappresentante nell'Unione europea (art. 27 RGPD), se applicabile, costituisce un obbligo strutturale distinto dall'"applicazione dello standard più protettivo in materia di diritti" sopra descritto — il primo richiede un punto di contatto formale stabilito nell'UE, non la mera replica dei meccanismi di accesso, portabilità e cancellazione. Questa informativa non valuta, in questa versione, se tale obbligo strutturale sia applicabile; tale valutazione dipende dal medesimo parere legale formale sopra già menzionato.

11Legislazione cantonale applicabile

Oltre alla LPD/nDSG federale, la registrazione e l'operatività del conducente sono soggette alla legislazione cantonale sui trasporti (ad esempio, LTVTC a Ginevra, regolamento 740.25 nel Cantone di Vaud, LMob art. 197 a Friburgo), con il requisito di un'autorizzazione propria come "diffuseur de course" (una categoria cantonale ginevrina di licenza per servizi di smistamento/intermediazione delle corse) in determinati cantoni, indipendentemente dallo status occupazionale del conducente. Questa informativa tratta esclusivamente il trattamento dei dati personali; la base regolatoria del trasporto è descritta nei documenti interni di conformità del progetto, non duplicata qui.

Ambito geografico effettivo di questa informativa: il regime di conservazione e trattamento dei dati personali descritto in questa informativa si applica alle operazioni effettivamente attive della piattaforma — oggi, ai cantoni la cui operatività è di fatto collegata, in particolare Zurigo. Il requisito è non negoziabile e reale: l'attivazione di Ginevra, Vaud o Friburgo richiede un previo parere legale cantonale formale di un avvocato svizzero abilitato (secondo la revisione di sicurezza e conformità interna di la piattaforma), e DirectTransfer non opera né tratta dati personali di corsa in questi tre cantoni finché tale parere non esiste. Stato di attuazione, con precisione — il meccanismo tecnico di blocco e la decisione giuridica di riattivazione non sono la stessa cosa: il meccanismo tecnico concreto che applica questo blocco — un gate fail-closed per cantone, applicato a ogni punto di ingresso che crea o riattiva un'autorizzazione cantonale del conducente — è già implementato nel servizio backend della piattaforma ed è coperto da test automatizzati che confermano il corretto blocco di Ginevra, Vaud e Friburgo, consentendo al contempo gli altri cantoni; non si tratta di una semplice proposta tecnica, la salvaguardia esiste già ed è oggi verificata, indipendentemente dall'ambiente. Ciò che resta in sospeso non è questo meccanismo tecnico, bensì il parere legale sostanziale di un avvocato svizzero abilitato che determinerà se e quando Ginevra, Vaud o Friburgo saranno riattivati; finché tale parere non esiste, il gate fail-closed continua a respingere qualsiasi tentativo di creare o riattivare un'autorizzazione del conducente in questi tre cantoni. Questa informativa sarà aggiornata con il regime cantonale specifico al momento dell'attivazione di qualsiasi nuovo cantone.

12Sicurezza delle informazioni (art. 8 LPD/nDSG)

Applichiamo misure tecniche e organizzative adeguate al rischio per garantire un livello di sicurezza dei dati appropriato e prevenire violazioni della sicurezza dei dati (art. 8 §1-2). Il disegno di sicurezza già congelato include il controllo di accesso basato sui ruoli (RBAC) e la sicurezza a livello di riga (Row Level Security, RLS) sulle tabelle di corsa, documento e dati personali, secondo la matrice RBAC e i requisiti RLS già specificati dalla revisione di sicurezza e conformità interna di la piattaforma.

Stato di attuazione, con precisione: il controllo di accesso basato sui ruoli (RBAC) è costruito, testato e operativo nel servizio backend della piattaforma per i flussi già costruiti ad oggi (registrazione del conducente, incluso l'accesso ai documenti, secondo la sezione 6); i flussi non ancora costruiti (corsa, chat, cronologia delle corse) non hanno ancora applicazione attiva, poiché il relativo modulo non esiste ancora. Le concrete policy di sicurezza a livello di riga del database (RLS) restano registrate soltanto come bozza interna, esplicitamente contrassegnata "STUB, NON RATIFICATO" — questa bozza fissa l'intento funzionale a livello SQL per accelerare il lavoro del team di sicurezza interno, ma non costituisce la politica finale; la ratifica da parte del team di sicurezza interno è precondizione prima che la RLS possa essere affermata come misura di sicurezza già attiva in produzione, anche per i flussi già costruiti. Questa sezione descrive quindi il disegno di sicurezza già congelato e l'architettura obiettivo; l'applicazione del RBAC è verificata operativamente per i flussi costruiti ad oggi, quella della RLS non ancora, in attesa di tale ratifica.

In caso di violazione della sicurezza dei dati suscettibile di comportare un rischio elevato per la vostra personalità o i vostri diritti fondamentali, notifichiamo l'IFPDT il più rapidamente possibile (art. 24 §1) e vi informiamo direttamente, se ciò è necessario alla vostra protezione o se l'autorità lo richiede (art. 24 §4).

13I vostri diritti

Ai sensi della LPD/nDSG, avete diritto a:

Informazione (art. 25): confermare se trattiamo dati personali che vi riguardano e ottenere, tra l'altro, l'identità e i recapiti del titolare del trattamento, i dati trattati stessi, la finalità, il termine di conservazione o il criterio per determinarlo (sezione 9), l'origine dei dati laddove non raccolti direttamente presso di voi, e i destinatari (sezione 7). Rispondiamo, di norma, entro 30 giorni (art. 25 §7), gratuitamente (art. 25 §6). Questo diritto non può essere oggetto di rinuncia anticipata (art. 25 §5).
Rettifica (art. 32): richiedere la rettifica di dati personali inesatti.
Portabilità (art. 28-29): richiedere l'esportazione, in un formato elettronico corrente, dei dati trattati con il vostro consenso o in collegamento diretto con un contratto che vi riguarda.
Opposizione a una comunicazione indebita (art. 30-31): la comunicazione dei vostri dati sensibili a terzi richiede un proprio motivo giustificativo (ad esempio, l'esecuzione di un contratto, art. 31 §2 al. a); potete contestare una comunicazione priva di tale motivo.
Reclamo presso l'autorità di vigilanza: potete presentare un reclamo all'IFPDT (art. 4).

13.1Diritto all'oblio — meccanismo attuale

La distruzione o l'anonimizzazione dei dati non appena non più necessari è un obbligo legale del titolare del trattamento, non un'opzione (art. 6 §4), e l'art. 32 consente di richiedere la rettifica di dati inesatti. Meccanismo attuale, definitivo finché il self-service non sarà implementato: qualsiasi richiesta di cancellazione anticipata dei vostri dati è trattata manualmente tramite il canale di contatto della sezione 15; rispondiamo entro il termine dell'art. 25 §7 (30 giorni), qui applicato per analogia alla richiesta di cancellazione — un'estensione ragionevole del termine, non una garanzia identica all'ambito letterale dell'art. 25 §7, che riguarda il diritto di accesso, non l'esecuzione di una richiesta di cancellazione, e pertanto soggetta a revisione da parte di un avvocato svizzero abilitato prima di essere trattata come termine definitivo; e confermiamo per iscritto l'esecuzione della richiesta o, ove applicabile, la base giuridica alla base di un eventuale rifiuto (ad esempio, un obbligo legale cantonale di conservazione documentale ancora in vigore, sezione 4.2). Un meccanismo di self-service diretto che consenta all'interessato di eseguire questa richiesta senza intervento manuale potrà essere reso disponibile in futuro; questa sezione sarà aggiornata quando ciò avverrà, senza modificare il diritto in sé, già garantito dal meccanismo manuale sopra descritto.

14Valutazione d'impatto sulla protezione dei dati (art. 22)

Riconosciamo che il trattamento di dati personali degni di particolare protezione su larga scala, come la verifica documentale del conducente (sezioni 4.2, 6), può far scattare l'obbligo di effettuare una valutazione d'impatto sulla protezione dei dati prima del trattamento, ai sensi dell'art. 22 §1-2 al. a. Questa valutazione è di responsabilità congiunta del team interno di sicurezza e conformità e del team legale interno prima del lancio, e il suo esito può comportare adeguamenti a questa informativa.

15Contatto

Per esercitare uno qualsiasi dei diritti di cui alla sezione 13, o per qualsiasi domanda su questo documento: privacidade@directtransfer.ch.

16Consenso, clickwrap e registrazione di audit

Laddove questa informativa o qualsiasi condizione di servizio richieda il vostro consenso — ad esempio, in fase di registrazione dell'account, in fase di presentazione del documento sensibile del conducente (sezione 6), o in fase di accettazione di questa stessa informativa — l'accettazione avviene tramite clickwrap esplicito, mai tramite inazione o navigazione silenziosa. Ogni accettazione genera una registrazione di audit contenente, come minimo: l'identificativo dell'utente che ha accettato, la versione esatta del documento accettato, e il timestamp dell'accettazione. Questa registrazione consente di dimostrare, in qualsiasi momento, cosa è stato accettato, da chi e quando — condizione di validità del consenso volontario e specifico richiesto dall'art. 6 §6 LPD/nDSG.

La struttura tecnica esatta di questa registrazione di audit (schema della tabella, conservazione del registro di consenso stesso) è di responsabilità del team di architettura dati competente, secondo la regola di governance ingegneristica interna di questo progetto sulla proprietà esclusiva dei contratti tecnici condivisi — questa informativa definisce il requisito legale, non lo schema tecnico.

17Modifiche alla presente informativa

Possiamo aggiornare questa informativa per riflettere una modifica nel trattamento dei dati, nella legge applicabile o nella piattaforma. Una modifica sostanziale viene comunicata in modo visibile prima della sua entrata in vigore, e ciascuna versione è identificata da numero e data, secondo lo stesso meccanismo di registrazione delle versioni della sezione 16.

Cronologia delle versioni:

Versione 1.0 — 2026-08-22: prima versione definitiva di questo documento, che sostituisce la precedente bozza di lavoro. Incorpora le correzioni già applicate in precedenti cicli di verifica incrociata interna di sicurezza e conformità e di dibattito critico avversariale interno, e definisce la posizione finale riguardo alla conservazione (sezione 9), all'ambito cantonale attivo (sezione 11), alla duplice informativa LPD/nDSG–RGPD per il modulo Cargo (sezione 10) e al meccanismo del diritto all'oblio (sezione 13.1). Riguardo all'informativa sulla chiamata GSM nativa (sezione 4.6), definisce il testo informativo e presenta l'inquadramento giuridico più prossimo disponibile (art. 19 §2 al. c + art. 6 §2), ma non definisce, da sola, la conferma della sufficienza giuridica di tale inquadramento per lo scenario specifico — tale conferma rimane in capo alla revisione di sicurezza e conformità interna di la piattaforma, secondo la nota della stessa sezione 4.6. Correzione puntuale del 2026-08-23 (sezione 11): il testo precedente descriveva il gate fail-closed di blocco cantonale come ancora "una proposta tecnica, non una decisione" — descrizione superata. La verifica tecnica diretta del codice ha confermato che il meccanismo è già implementato e coperto da test automatizzati; resta in sospeso solo il parere legale sostanziale di un avvocato svizzero abilitato sulla riattivazione di tali cantoni. Friburgo è stato inoltre aggiunto esplicitamente accanto a Ginevra e Vaud, essendo ugualmente bloccato nel codice.