Privacy e compliance by design
Software che nasce conforme,
non che viene sistemato dopo
La conformità aggiunta a fine progetto è la più costosa: significa tornare su un’architettura già decisa e cambiare dove risiedono i dati, chi vede cosa e come si cancella. Se le stesse domande arrivano in fase di analisi costano qualche riunione, e quasi sempre semplificano anche il prodotto.
Le decisioni normative sono decisioni di architettura
Quando un progetto parte, le domande che sembrano legali sono in realtà tecniche. Quali dati servono davvero per far funzionare la cosa? Dove vengono elaborati? Per quanto tempo restano? Chi può vederli, e come lo dimostriamo fra sei mesi? Ognuna di queste risposte cambia il modello dati, la scelta del fornitore cloud e la struttura dei permessi. Prese all’inizio sono scelte; prese dopo il go-live sono rifacimenti.
Il caso più chiaro riguarda l’intelligenza artificiale. Mandare un documento a un servizio esterno o far girare un modello sulla macchina di chi lavora sono due architetture diverse con costi, prestazioni e implicazioni normative diverse. È una decisione di prodotto che va presa consapevolmente all’inizio, perché cambiarla dopo significa riscrivere la parte centrale del sistema. Il caso studio pii-legal nasce esattamente da questo vincolo: un’app che riconosce dati personali dentro atti giudiziari senza che il documento esca dal computer.
Il principio non è nuovo e non ce lo siamo inventato noi: la protezione dei dati fin dalla progettazione è scritta nel GDPR, e il settore ha prodotto anche strumenti specifici, come il codice di condotta per le imprese di sviluppo di software gestionale approvato dal Garante privacy nel 2024. Quello che manca quasi sempre non è la regola, è qualcuno che la applichi mentre il software viene costruito.
Situazioni in cui questo lavoro serve davvero
State per iniziare un progetto
Il momento in cui questi vincoli costano meno di tutto
Il prodotto tratterà dati sensibili
Salute, dati giudiziari, informazioni finanziarie
Volete integrare AI in un software
Cambia il perimetro normativo di un prodotto già esistente
Vendete a clienti che fanno audit
Enterprise, sanità, pubblica amministrazione, banche
Un adeguamento vi ha lasciato una lista
Interventi tecnici che nessuno ha ancora implementato
State migrando un sistema legacy
L’occasione giusta per sistemare permessi e conservazione
Concretamente
Cosa entra nel progetto
Minimizzazione dei dati
La revisione più utile e la più trascurata: quali campi state raccogliendo senza usarli. Ogni dato che non entra nel sistema è un rischio che non dovrete gestire.
Residenza ed elaborazione
Dove risiedono i dati e dove vengono elaborati, compresi i servizi di terzi che il software chiama. Scelta esplicita in fase di architettura, non conseguenza del fornitore più comodo.
Ruoli e permessi
Chi vede cosa, con una granularità che regge davvero: il profilo unico "amministratore" è il modo più veloce per rendere indifendibile qualunque documento scritto sopra.
Log e tracciabilità
Registrazione degli accessi e delle operazioni sui dati, conservata per un periodo definito. È ciò che trasforma un’affermazione in una prova quando arriva una contestazione.
Conservazione e cancellazione
Periodi di conservazione applicati dal sistema e non affidati alla memoria di qualcuno, con cancellazione selettiva che non distrugge i dati che la legge impone di tenere.
Esportazione e portabilità
Una funzione che estrae i dati di una persona o di un cliente in un formato leggibile, così che rispondere a una richiesta non sia un lavoro manuale sul database.
Trasparenza nell’interfaccia
Informative e avvisi nel punto in cui servono, compresa l’indicazione quando l’utente sta interagendo con un sistema di AI o guardando un contenuto generato.
Documentazione tecnica
Le evidenze che servono a un audit prodotte durante lo sviluppo: schema dei dati, fornitori coinvolti, misure adottate, versioni dei modelli utilizzati.
I vincoli normativi entrano nelle prime 2 settimane di analisi
Requisiti normativi
Prima di scrivere codice mettiamo sul tavolo i vincoli: che dati personali servono davvero, quali si possono non raccogliere, dove risiedono, chi li vede. Le domande costano poco adesso e moltissimo dopo il go-live.
Scelte tecniche vincolate
Architettura, fornitori cloud, modelli AI e log vengono scelti anche in base a dove finiscono i dati e a cosa dice il contratto del fornitore. Un modello che si addestra sui vostri input è una scelta di prodotto, non un dettaglio.
Costruzione e documentazione
Sviluppiamo mentre il team legale prepara informative, registro dei trattamenti e documentazione tecnica. Alla consegna il software funziona e le carte esistono: non sono due progetti separati con due date diverse.
Verifica prima del rilascio
Prima del go-live ricontrolliamo insieme cancellazioni, esportazioni, ruoli, retention e trasparenza verso l’utente. È la lista che, quando manca, torna indietro sotto forma di richiesta di un cliente o di un’autorità.
FAQ
Sviluppo conforme: domande frequenti
Le risposte che diamo più spesso alle aziende che ci scrivono su questo tema.
In fase di analisi quasi nulla: sono domande in più durante le riunioni iniziali e qualche scelta architetturale presa con più attenzione. Il costo compare quando le stesse esigenze arrivano dopo il rilascio, perché a quel punto si tocca un sistema in produzione con dati veri dentro. Nella nostra esperienza la fase di analisi si allunga di poco e in cambio si accorcia, perché la minimizzazione elimina funzionalità che nessuno aveva davvero chiesto.
Sì, con un approccio diverso: invece di decidere si valuta. Si guarda cosa il sistema fa oggi, si confronta con quello che i documenti dichiarano e si ottiene una lista di interventi ordinata per rischio e per costo. Di solito una parte si chiude in pochi giorni, come retention, permessi e log, mentre una parte richiede lavoro strutturale, che si pianifica insieme alle altre evoluzioni del prodotto.
Cambia il perimetro normativo del prodotto, ed è la cosa che più spesso viene scoperta tardi. Finché il software applica regole fisse decise da chi lo ha scritto, la valutazione è una; quando una parte delle decisioni passa a un modello, si aggiungono gli obblighi dell’AI Act, la questione di cosa il fornitore fa con gli input e la necessità di prevedere una supervisione umana nei punti che contano. Sono verifiche da fare prima dell’integrazione, non dopo.
Sì, ed è una richiesta frequente. In questi casi partiamo da una verifica tecnica del sistema esistente e dai documenti che lo accompagnano, e restituiamo la lista degli scostamenti. Gli interventi possono poi essere realizzati da noi o dal fornitore che già lo mantiene: in questo secondo caso consegniamo requisiti tecnici scritti in modo che siano implementabili senza ambiguità.
No, ne copre la metà che di solito resta scoperta. Il consulente stabilisce cosa la norma richiede per la vostra organizzazione; qui si tratta di far sì che il software lo faccia davvero. Quando il consulente c’è già, lavoriamo sulle sue indicazioni; quando non c’è, la parte normativa la copre il team legale interno.
Preventivo
Parliamone prima di scrivere codice
Descriveteci la situazione, anche in due righe. La prima call è gratuita e senza impegno: serve a capire da dove conviene partire. Rispondiamo entro 24 ore.
Richiesta inviata
Grazie! Ti ricontattiamo entro 24 ore per una prima call gratuita e senza impegno.
Torna alla homeInvio non riuscito
Qualcosa è andato storto. Riprova tra poco oppure scrivici direttamente a info@morfex.it.
RiprovaCollegato a questa pagina
- Adeguamento GDPR La parte documentale che accompagna gli interventi tecnici
- Adeguamento AI Act Cosa cambia quando l’AI entra in un prodotto esistente
- Caso studio: anonimizzazione documenti Un vincolo normativo diventato scelta di architettura
- Sviluppo software e piattaforme Il servizio di sviluppo completo
- Sviluppo AI su misura Agenti, automazioni e modelli con supervisione umana
- Legal & Compliance L’hub con tutte le aree e il metodo di lavoro