PIPELINEGuide
Software personalizzato e privacy: cosa richiede il GDPR
Non appena nel software personalizzato vengono trattati dati personali, valgono obblighi chiari. Quali sono concretamente, cosa manca quasi sempre nella pratica e cosa basta effettivamente.
Non appena nel software personalizzato vengono trattati dati personali, servono base giuridica, vincolo di finalità, termini di cancellazione definiti, informativa agli interessati e un contratto di responsabilità del trattamento con ogni fornitore coinvolto. Nella pratica mancano quasi sempre gli stessi tre punti: il termine di cancellazione, l'informativa nel punto di raccolta e il chiarimento se il fornitore utilizza i dati per proprio training.
01 — Privacy
Cosa richiede il GDPR
Non appena vengono trattati dati personali — e questo avviene più velocemente di quanto si pensi, ad esempio quando qualcuno inserisce un nome o un numero di telefono — valgono i soliti obblighi: indicare la base giuridica, definire lo scopo, rispettare la minimizzazione dei dati, definire i termini di cancellazione, informare gli interessati.
In pratica questo significa per il software personalizzato: un contratto di responsabilità del trattamento con ogni fornitore coinvolto, la verifica di dove viene effettuato il trattamento, un termine di cancellazione documentato e un passaggio comprensibile nell'informativa sulla privacy. Tre cose mancano quasi sempre nella pratica: il termine di cancellazione definito, l'informativa nel punto in cui i dati vengono raccolti e il chiarimento se il fornitore utilizza i dati per proprio training.
Una valutazione d'impatto sulla protezione dei dati è necessaria solo in caso di rischio presumibilmente elevato — non per la maggior parte dei progetti di questo tipo. La verifica stessa dovrebbe comunque essere documentata, così da poter dimostrare, in caso di necessità, perché è stata omessa.
02 — Contratto
Cosa va chiarito per iscritto
- Proprietà di dati e accessi. Appartengono al committente. Se un fornitore non lo conferma chiaramente, questa è l'informazione più importante del colloquio.
- Restituzione alla fine del rapporto. In quale formato, in quale termine, a quali costi.
- Nessuna durata minima senza contropartita. Il vincolo è giustificabile se viene fornito qualcosa in cambio — altrimenti no.
- Quanto costa una modifica successiva. Non è il prezzo del progetto a decidere i costi complessivi, ma la tariffa oraria del terzo anno.
- Documentazione come oggetto di consegna. Non come promessa, ma come voce nell'offerta.
03 — Rischi
Cosa può andare storto
- Il sistema risponde in modo errato. Limitabile facendolo lavorare esclusivamente con contenuti verificati e facendolo inoltrare in caso di incertezza invece di indovinare. Questa è una scelta di configurazione, non una proprietà della tecnologia.
- L'impegno viene sottovalutato. Motivo più frequente: situazione di partenza poco chiara. Un inventario onesto prima dell'offerta previene questo problema in modo più affidabile di qualsiasi margine.
- Nessuno lo aggiorna. Il rischio maggiore in assoluto — e il più facilmente evitabile.
- Lacune nella privacy. Nascono quasi sempre da termini di cancellazione mancanti e responsabilità poco chiare, raramente dalla tecnologia stessa.
- Dipendenza dal fornitore. Evitabile se accessi, dati e documentazione sono contrattualmente di proprietà del committente.
04 — Domande
Domande frequenti
Come evitiamo che il progetto sfugga di mano?
Piccoli passi con risultato utilizzabile, budget fissi per passo, e possibilità di uscire dopo ogni passo. I grandi progetti a prezzo fisso su dodici mesi sono la strada più sicura verso la delusione — per entrambe le parti.
Possiamo iniziare con un foglio di calcolo?
Spesso sì, ed è un buon test. Se il foglio rappresenta il processo e fallisce solo per multiutenza, permessi o volume di dati, il requisito è chiaro e il progetto è calcolabile.
A chi appartiene il codice sorgente?
A te, completamente, dal pagamento. È scritto nel contratto. Puoi andare con quello da qualsiasi altro sviluppatore — questo è il punto.
Cosa succede se durante lo sviluppo scopriamo nuovi requisiti?
È normale e previsto, perché si lavora con piccoli passi. Un nuovo requisito viene incluso nel passo successivo, invece di bloccare l'intero progetto.
Quanti utenti può gestire un sistema del genere?
Dipende dall'architettura, che pianifichiamo in base alla tua crescita prevista — da pochi utenti nella propria attività fino a diverse centinaia su più sedi.
Quando conviene un software proprio rispetto a un software standard?
Quando il tuo processo è un vero vantaggio competitivo, quando il software standard si adatta solo al settanta percento e il resto finisce in lavoro manuale, o quando i costi di licenza per utente superano lo sviluppo nell'arco di pochi anni. Se si tratta solo di comodità, il software standard costa meno.
Funziona sui nostri server o nel cloud?
Entrambe le opzioni sono possibili. Per la maggior parte delle attività una soluzione cloud richiede meno manutenzione; dove i dati non possono uscire dalla sede, lo configuriamo su infrastruttura propria.
05 — Prosegui
Pagine correlate
- Software personalizzato — Panoramica
- Software personalizzato — Costi
- Software personalizzato — Da dove iniziare
- Software personalizzato — Misurare il successo
- Software personalizzato — Confronto fornitori
- Software personalizzato — Rischi
- Software personalizzato — Piccole imprese
- Software personalizzato — Agevolazioni
- Automazione dei processi
- Integrazione CRM
- Interfacce API
- Tutte le guide
Software personalizzato per regione
Prossimo passo
Inviateci qualche frase sul vostro progetto.
Leggiamo ogni richiesta personalmente e rispondiamo di persona. Niente team vendite, nessun modulo di richiamata nel vuoto.