Posso raccogliere indirizzi IP? Che cosa registra in silenzio il vostro modulo
Di norma sì — un indirizzo IP è un dato personale, non un dato vietato. La domanda difficile riguarda tutto il resto: user agent, marche temporali, referrer, misure di tempo, EXIF delle foto, intestazioni delle e-mail di notifica, registri di errore e richieste di terzi dal lato di chi risponde. Un inventario campo per campo, lo statuto giuridico di ciascun elemento secondo nLPD e GDPR, tempi di conservazione difendibili e una dichiarazione chiara di che cosa Schweizerform registra e che cosa no.
«Posso raccogliere indirizzi IP?» è quasi sempre la prima domanda sbagliata. La risposta di solito è sì, ed è l'aspetto meno interessante del tema — perché l'indirizzo IP è l'unico metadato che tutti sanno di raccogliere. A far naufragare una promessa di anonimato è tutto il resto: lo user agent, la marca temporale al millisecondo, il referrer che rivela da quale pagina interna si arrivava, le misure di tempo, le coordinate GPS nella foto allegata, le intestazioni dell'e-mail di notifica e le sei richieste verso terzi che la pagina del modulo effettua prima che qualcuno abbia digitato una parola.
In breve
Sì, potete raccogliere un indirizzo IP — è un dato personale ai sensi della nLPD e del GDPR, non un dato vietato. Servono una finalità, una base giuridica, trasparenza e un tempo di conservazione coerente con la finalità. Sicurezza e contrasto agli abusi sono le giustificazioni solide; «per le statistiche» di regola no, perché basterebbe un segnale più grossolano. I problemi stanno altrove. La maggior parte delle piattaforme registra per impostazione predefinita una dozzina di altre cose, quasi nessuna pubblica l'elenco, ed è l'accumulo a trasformare un canale «anonimo» in uno pseudonimo che la vostra stessa informatica può risolvere. Questo articolo fornisce l'inventario, lo statuto giuridico di ogni voce, tempi difendibili, una verifica di dieci minuti sul vostro modulo — e, alla fine, campo per campo, che cosa registra Schweizerform, comprese le parti meno private del resto del prodotto.
L'inventario: tutto ciò che un modulo può captare oltre alle risposte
È l'elenco da percorrere con la vostra piattaforma, non un atto d'accusa. Fornitori diversi raccolgono sottoinsiemi diversi; il punto è poter dire quale riguarda voi.
| Segnale | Da dove arriva | Che cosa può rivelare |
|---|---|---|
| Indirizzo IP | Ogni richiesta HTTP — il server lo vede, che lo conservi o no | Posizione approssimativa, datore di lavoro o provider, e un collegamento fra invii diversi dalla stessa rete |
| User agent e dati del dispositivo | Intestazioni della richiesta; talvolta dimensione dello schermo e piattaforma via JavaScript | Un'impronta sorprendentemente stretta — una combinazione insolita di versione del browser, sistema e risoluzione è quasi unica in un gruppo piccolo |
| Marche temporali | Orologio del server, con la precisione che il fornitore conserva | Incrocio con badge, turni, calendari. Un invio alle 03:12 di domenica restringe molto il cerchio |
| Referrer e parametri UTM | La pagina da cui proveniva la persona | Che arrivava da una precisa pagina intranet, da un link privato o da una campagna mirata |
| Telemetria di tempo e interazione | JavaScript sulla pagina: tempo per campo, esitazioni, correzioni, talvolta i tasti premuti | L'esitazione su una domanda delicata. All'estremo (session replay) anche risposte digitate e poi cancellate |
| Cookie e archiviazione locale | Impostati dalla pagina del modulo o da terzi incorporati | Visite ripetute, collegamento fra moduli e — con tracciatori di terzi — attività ben oltre il vostro modulo |
| Metadati dei file (EXIF) | Foto e documenti allegati da chi risponde | Coordinate GPS, ora di scatto, seriale del dispositivo; nei file d'ufficio autore e cronologia delle modifiche |
| Intestazioni dell'e-mail di notifica | Il messaggio che la piattaforma invia all'arrivo di una risposta | I server coinvolti — e, se le risposte sono nel corpo, una copia non cifrata permanente in più caselle |
| Monitoraggio di errori e prestazioni | Strumenti di terzi per crash/APM sulla pagina del modulo | URL, frammenti del payload, talvolta valori dei campi nei contesti d'errore |
| Richieste a CDN, font e CAPTCHA | Tutto ciò che la pagina carica da un altro host | L'indirizzo IP e lo user agent di chi risponde vengono comunicati a quell'host, che voi lo chiamiate «condivisione» o no |
| Identificativi di account | Un modulo dietro login aziendale o SSO | Tutto. Se la persona è autenticata, il resto dell'elenco non conta più |
Il problema dell'accumulo
Nessuna singola voce dell'elenco identifica da sola una persona in una popolazione ampia. Quattro insieme identificano la maggioranza delle persone in un'organizzazione di duecento. Per questo «non conserviamo i nomi» non è un'affermazione di anonimato, e per questo la domanda onesta non è «raccogliamo l'IP» ma «qual è il gruppo più piccolo da cui questo invio può provenire».
Un indirizzo IP è un dato personale?
Secondo l'art. 5 lett. a nLPD sono dati personali tutte le informazioni concernenti una persona fisica identificata o identificabile. Un indirizzo IP concerne una persona non appena esistano mezzi il cui impiego è ragionevolmente prevedibile — e nell'UE la Corte di giustizia ha risolto la questione equivalente in Breyer (C-582/14, 2016): un indirizzo IP dinamico è dato personale per il gestore del sito che dispone di mezzi giuridici per ottenere l'identità dal provider. Trattate un IP come dato personale. La posizione contraria non si vince e comunque non serve a nulla.
Ciò che si è mosso di recente riguarda i dati pseudonimizzati. Nel settembre 2025 la Corte di giustizia ha stabilito in GEPD c. SRB (C-413/23 P) che l'identificabilità si valuta in modo relativo: dati sufficientemente pseudonimizzati possono essere dati personali per il titolare originario e non esserlo per un destinatario che non può ragionevolmente re-identificare nessuno, tenuto conto di fattori tecnici, organizzativi e giuridici.
La cosa riguarda direttamente le piattaforme per moduli, perché è la differenza fra due impostazioni che entrambe dichiarano di «non conservare IP»:
- Un hash dell'IP con un algoritmo fisso e noto. Reversibile per forza bruta — lo spazio IPv4 si enumera in pochi secondi. Non è pseudonimizzazione ma offuscamento, e va trattato come un IP.
- Un hash con chiave e un segreto che l'attaccante non ha, salato per modulo. Non reversibile senza il segreto lato server e non collegabile fra moduli, perché lo stesso indirizzo produce un hash diverso per ciascun modulo. È davvero un altro oggetto — e l'approccio relativo è ciò che consente di dirlo.
- Nessun identificatore. Nulla da invertire, nulla da comunicare, nulla da conservare. Sempre la posizione più forte — e quella da scegliere ogni volta che la finalità è raggiungibile altrimenti.
La distinzione di fondo — anonimo o pseudonimo, e perché la maggior parte dei moduli «anonimi» non è né l'uno né l'altro — è in moduli anonimi o pseudonimi.
Quando la raccolta è difendibile — e per quanto tempo
Il diritto svizzero non richiede il consenso per la maggior parte dei trattamenti da parte di privati; richiede liceità, proporzionalità, riconoscibilità e buona fede (art. 6 nLPD), con l'interesse preponderante dell'art. 31 disponibile dove serva un motivo giustificativo. La via GDPR per gli stessi fatti è di regola il legittimo interesse dell'art. 6 par. 1 lett. f con bilanciamento documentato. In entrambi i sistemi la domanda decisiva è se un mezzo meno invasivo raggiungerebbe la stessa finalità. I metadati falliscono questo test molto più spesso dei campi del modulo.
| Finalità | Difendibile? | Conservazione sensata |
|---|---|---|
| Log di sicurezza — rilevamento intrusioni, analisi di incidenti | Sì, è il caso più solido | Da giorni a pochi mesi, poi cancellazione automatica. Non «per sempre, per ogni evenienza» |
| Rate limiting e blocco del traffico abusivo | Sì, ma non richiede conservazione oltre la finestra | La durata della finestra; blocchi con data di scadenza |
| Prevenzione degli invii duplicati | Sì con un valore derivato, discutibile con l'indirizzo stesso | Solo quanto l'invio; cancellare entrambi insieme |
| Prevenzione frodi su moduli con pagamento | Di norma sì, con il ragionamento documentato | Allineare al termine di contestazione o storno, poi cancellare |
| «Analytics» — da dove arrivano le risposte | Raramente — un paese o un contatore grossolano bastano senza l'indirizzo | Non conservare l'indirizzo; conservare il valore derivato |
| Dimostrare in seguito chi ha inviato | Solo con una reale esigenza probatoria — e allora dirlo prima | Determinata dall'obbligo sottostante, non dalla comodità |
| Su un modulo che promette anonimato | No. La finalità contraddice la promessa | Non applicabile — non raccogliere |
Qualunque sia la scelta, ne derivano tre obblighi, ed è su quelli che si viene controllati: i metadati vanno nel registro delle attività di trattamento, le categorie nell'informativa ai sensi dell'art. 19 nLPD (destinatari e paesi inclusi), e la regola di conservazione deve esistere per iscritto ed essere eseguita davvero. Vedi conservazione dei dati dei moduli e la checklist nLPD per moduli e sondaggi.
Il livello di cookie e tracciatori segue un'altra regola
La Svizzera disciplina i cookie nel diritto delle telecomunicazioni, non nella legge sulla protezione dei dati. L'art. 45c lett. b LTC consente il trattamento sul dispositivo se l'utente è informato del trattamento e della sua finalità e reso attento alla possibilità di rifiutarlo — un modello informazione più opposizione, non quello europeo del consenso preventivo. L'IFPDT ha pubblicato una guida sui trattamenti mediante cookie e tecnologie analoghe (versione 1.1 del 6 ottobre 2025) che si attende una possibilità di rifiuto visibile ed esercitabile in pochi clic anziché sepolta. Se vengono trattati dati personali si aggiunge la nLPD; e se chi risponde si trova nell'UE, per costoro vale lo standard di consenso ePrivacy indipendentemente dalla vostra sede.
Per la pagina di un modulo la regola pratica è molto più semplice del diritto: niente tracciatori non essenziali. Un modulo che non carica analytics, tag manager, font esterni né CAPTCHA di terzi non ha bisogno di alcun banner, non comunica a nessuno l'IP di chi risponde e converte meglio perché prima della prima domanda non c'è alcuna finestra. Pubblicità e misurazione appartengono alle pagine di marketing, dove il compromesso è una vera decisione aziendale e non un incidente.
I quattro che non sapevate di raccogliere
1. I dati EXIF nelle foto caricate
Una foto scattata col telefono porta spesso coordinate GPS, ora dello scatto e identità del dispositivo. Chi fotografa un difetto in casa, una lesione o un documento sul tavolo della cucina allega il proprio indirizzo privato a una segnalazione che credeva anonima. Rimuovete i metadati al caricamento dove possibile; dove non è possibile, scrivetelo in una frase accanto al campo. Sul percorso di caricamento vedi la guida completa ai caricamenti sicuri.
2. L'e-mail di notifica
Se la piattaforma vi invia per e-mail il contenuto della risposta, avete creato copie non cifrate permanenti in ogni casella della lista di distribuzione, su ogni telefono sincronizzato e in ogni backup — più una traccia di posta con proprie intestazioni e propria conservazione. La correzione è un'impostazione: notificare che è arrivata una risposta, non includere mai il contenuto.
3. Monitoraggio degli errori e session replay
Gli strumenti di crash reporting e di session replay si installano per migliorare il prodotto e sono di norma invisibili a chi redige l'informativa. Entrambi possono captare valori dei campi — il replay per costruzione, il monitoraggio degli errori per caso, dentro payload e contesti d'errore. Su un modulo che tratta salute, HR o materie legali, uno script di replay di terzi è una comunicazione di dati degni di particolare protezione a un responsabile che nessuno ha documentato.
4. Tutto ciò che la pagina carica da un altro host
Un font web, una libreria di icone, una CDN, un CAPTCHA: ciascuno riceve indirizzo IP e user agent di chi risponde come condizione per consegnare il file. È una comunicazione — e se l'host è all'estero, una comunicazione transfrontaliera la cui base ai sensi degli art. 16/17 va documentata. È anche la cosa più facile da verificare di questa pagina: vedi la verifica qui sotto e quali strumenti per moduli sono ospitati in Svizzera.
Che cosa registra Schweizerform — campo per campo
Lo pubblichiamo perché lo chiediamo agli altri fornitori. In Schweizerform un invio è una riga di database più un blob cifrato in uno storage a oggetti svizzero. Questa è l'intera riga:
| Registrato | Che cos'è | Perché |
|---|---|---|
| ID invio, ID modulo, percorso di archiviazione | Identificativi del record e del suo testo cifrato | Servono per leggere e cancellare l'invio |
| Chiave incapsulata e IV | La chiave AES dell'invio, cifrata sotto la chiave pubblica del modulo | Solo la chiave privata del proprietario la apre — il server non può |
| Data di arrivo, data di lettura | Quando è arrivato e quando il proprietario l'ha decifrato la prima volta | Ordinamento della casella e indicatore «non letto» |
| Dimensione in byte | Totale dei byte cifrati archiviati | Contabilizzazione della quota di spazio |
| Durata, numero di risposte, numero di domande | Tre interi grossolani: tempo dall'apertura all'invio, quante domande hanno avuto risposta, quante ce n'erano | Analisi di completamento. Limitata, priva di identità, mai per domanda e per persona |
| Lingua di invio | Quale delle quattro lingue era visualizzata | Reportistica multilingue. Validata sull'elenco supportato, altrimenti vuota |
| Hash del mittente — solo se attivate «una volta per rete» | Un HMAC con chiave di (ID modulo + IP) sotto un segreto lato server | Prevenzione dei duplicati. Salato per modulo quindi non collegabile fra moduli, non reversibile a un indirizzo, e cancellato con l'invio |
| Marcatore di lotto perso | Vuoto, salvo che l'account abbia subito un reset della chiave della cassaforte senza codice di recupero | Quarantena invece di cancellazione — il testo cifrato è conservato per essere recuperato o eliminato deliberatamente |
| Etichette che applicate voi | Brevi etichette aggiunte dal proprietario dopo la decifratura, archiviate in chiaro | Filtro e triage nella casella senza decifrare prima tutto. Scritte da voi, mai da chi risponde |
E questo è ciò che non c'è: nessun indirizzo IP, nessuno user agent, nessun dato di dispositivo o browser, nessun referrer, nessuna geolocalizzazione, nessun identificativo di cookie o visitatore, nessun tempo di risposta per domanda e nessun account — chi risponde non ne ha mai bisogno. Una pagina pubblica di modulo incrementa un contatore giornaliero di visualizzazioni (e uno separato per le scansioni QR); non crea un record di visita. Le statistiche per domanda sono contatori aggregati piatti: il client segnala quali domande hanno avuto risposta, il server incrementa e scarta la segnalazione.
Le parti meno private, dette chiaramente
Il nostro sito di marketing — le pagine che state leggendo, non quelle dei moduli — usa un'analitica interna che conserva un'impronta di browser grossolana, lo user agent grezzo e un paese derivato dal vostro IP tramite un database MaxMind GeoLite2 locale; l'IP stesso non viene mai persistito e non viene contattato alcun servizio di analytics esterno. In esercizio, i record di rate limiting contengono IP grezzi per la durata della loro finestra e poi vengono ripuliti, e i blocchi IP conservano un indirizzo finché il blocco dura — in entrambi i casi contro gli abusi. Il registro di audit annota IP e user agent per le azioni dei titolari di account (accessi, modifiche ai moduli, consultazione o cancellazione di un invio), perché un registro di audit che non sa dire da dove è arrivata un'azione non è un registro di audit. Nulla di tutto ciò riguarda chi risponde ai vostri moduli. Se un fornitore non sa scrivervi questo paragrafo su di sé, quello è il risultato della verifica.
Il ragionamento dietro l'hash «una volta per rete» — perché un sale per modulo e un pepe lato server sono le tre proprietà che rendono difendibile un identificatore derivato, e come si confrontano gli altri meccanismi anti-duplicato in termini di costo per l'anonimato — è in prevenire spam, bot e invii duplicati senza rompere l'anonimato.
Verificate il vostro modulo in dieci minuti
Aprite il modulo in produzione con l'ispettore di rete
Strumenti per sviluppatori, scheda Rete, ricaricate. Ogni host distinto in quell'elenco riceve l'indirizzo IP di chi risponde. Annotateli; ciò che non sapete spiegare è rimovibile oppure è una comunicazione da dichiarare.
Inviate una risposta di prova e guardate che cosa è stato conservato
Esportatela o aprite il record via API. È nell'export che compaiono le colonne di metadati nascoste — IP, user agent, geolocalizzazione, dispositivo, tempi. Se l'export ha colonne che l'informativa non menziona, avete trovato lo scarto.
Controllate i cookie prima e dopo
Scheda Applicazione, Cookie e archiviazione locale, prima del caricamento e dopo l'invio. Tutto ciò che imposta un host diverso dal vostro è un tracciatore di terzi su una pagina di modulo e lì non ci deve stare.
Caricate una foto da telefono e rileggetene i metadati
Basta un qualsiasi visualizzatore EXIF. Se le coordinate sopravvivono al percorso, rimuovete i metadati al caricamento o avvisate accanto al campo.
Leggete un'e-mail di notifica come un documento
Contiene risposte? Allora quelle risposte ora vivono in ogni casella della lista. Disattivate il contenuto e tenete l'avviso.
Ponete due domande scritte al fornitore
«Quali metadati conservate per invio e per quanto tempo?» e «Quali subincaricati li ricevono?» Salvate la risposta con la data — è ciò che servirà davanti a un controllo, e già il tempo di risposta dice qualcosa.
Scrivete la regola di conservazione e fatela girare
Per categoria: log di sicurezza, record di rate limiting, invii, export, backup. Una regola che nessuno esegue è peggio di nessuna regola, perché documenta un'intenzione che dimostrabilmente non rispettate.
Nessuno ha mai deciso di raccogliere i metadati. È esattamente questo il problema — una decisione non presa resta una decisione, ed è quella che vi verrà chiesto di difendere.
In sintesi
Potete raccogliere indirizzi IP? Di norma sì — con una finalità, una base giuridica, una riga nell'informativa e un tempo di conservazione che finisce. Ciò che non va fatto: raccoglierli per impostazione predefinita, tenerli a tempo indeterminato e nel frattempo descrivere il modulo come anonimo. Queste tre abitudini trasformano un dettaglio tecnico in un rilievo di protezione dei dati.
Il modello mentale utile: ogni modulo ha due carichi — le risposte, che avete progettato, e i metadati, arrivati da soli. Il primo lo governate con l'elenco dei campi, il secondo con la piattaforma scelta e con le impostazioni che non avete toccato. Andate a guardare il secondo: dieci minuti bastano, e quasi tutti quelli che lo fanno trovano almeno una cosa che non avrebbero accettato.
Schweizerform registra i campi elencati sopra e nient'altro: risposte cifrate nel browser di chi risponde, nessun IP, nessuno user agent, nessun cookie sulla pagina del modulo, nessuna richiesta di terzi, e invii cifrati archiviati in Svizzera in ogni piano, gratuito compreso. La descrizione tecnica completa è sulla nostra pagina sicurezza, la guida pratica è creare un modulo online sicuro.
Avvertenza: questo articolo è informazione generale e contenuto di marketing, non consulenza legale. I riferimenti alla nLPD (art. 5 lett. a, 6, 16, 17, 19, 31), al GDPR (art. 6 par. 1 lett. f), all'art. 45c LTC, alla guida dell'IFPDT su cookie e tecnologie analoghe (v. 1.1 del 6 ottobre 2025), alla CGUE Breyer (C-582/14) e alla CGUE GEPD c. SRB (C-413/23 P, 4 settembre 2025) sono sintesi semplificate di una situazione verificata a luglio 2026; il diritto e la sua interpretazione cambiano. Le affermazioni su Schweizerform descrivono il prodotto a quella data e possono cambiare — fa fede la pagina sicurezza. Il comportamento dei prodotti di terzi varia per fornitore e piano; verificatelo voi stessi con la procedura sopra.