Come vengono gestiti i dati.

Anonimizzare può rendere più difficile proprio l'analisi che il modello deve svolgere.

Per questo i nostri plugin, in generale, non anonimizzano i dati; lo fanno solo quando ciò non incide sul processo.

I dati vengono filtrati e aggregati localmente quando il processo lo consente, ma alcuni dati personali possono comunque essere trattati dal modello.

Se si caricano dati personali, è necessario avere un DPA con il provider del modello.

Dopo ogni esecuzione sostanziale di Vera, un report compatto registra ogni fase visibile al modello nelle unità proprie del processo. Distingue l'estensione disponibile della fonte, ciò che il codice ha elaborato localmente, ciò che è stato visibile al modello, quale parte non è mai stata visibile al modello, il motivo del contesto e la base probatoria disponibile. Quando l'ambiente può scrivere file, Vera conserva un report JSON e una versione Markdown nell'output dell'esecuzione; altrimenti mostra il report in chat e dichiara che non è stato creato un report durevole. Il totale elaborato localmente e la parte mai visibile al modello si sovrappongono: non sono categorie alternative da sommare.

Un possibile percorso di codice più ristretto compare soltanto quando le evidenze dell'esecuzione lo sostengono e indicano come proteggere la qualità analitica. Un documento o una popolazione rilevante completa può essere il minimo corretto. Il report non è monitoraggio di rete, attestazione del provider, DPIA, parere legale o certificazione GDPR; un hash registrato lega la ricevuta ai byte ma non prova la consegna lato provider.

Il comando di Vera che genera il report con ricevuta invia automaticamente a Mparanza quattro campi: versione dello schema, identificativo casuale della ricevuta, versione di Vera e impronta SHA-256 del report locale. Mparanza aggiunge data server e firma Ed25519 e conserva quei soli campi di prova, senza report, dati del cliente, nomi dei file, contenuti o hash dei documenti fonte. L'HTML risultante può essere inviato al cliente, salvato come PDF e verificato nella pagina pubblica. Prova soltanto esistenza, data server e integrità del report; non prova autonomamente chi ha presentato il digest. Se il servizio non è disponibile, il lavoro e il report locale restano completati e la richiesta rimane in attesa per un nuovo tentativo.

La lettura di un report esistente, il generatore locale generico di Studio Archive e il percorso di onboarding esplicitamente locale non richiedono la ricevuta server. Il servizio delle ricevute opera in Finlandia, nell’UE, e conserva la prova firmata senza scadenza automatica. L’IP non è salvato nel database delle ricevute: serve all’endpoint per limitare richieste eccessive ed è registrato separatamente nei log degli accessi. Nginx conserva 14 archivi giornalieri più il file corrente; per il log applicativo Uvicorn non è stata individuata una durata massima prefissata e lo script operativo lo sovrascrive al riavvio. Da attuare: limite di conservazione di 14 giorni, con cancellazione automatica dei log tecnici. Le ricevute firmate restano escluse da questa cancellazione.

L’hash SHA-256 è un’impronta di 64 caratteri calcolata localmente dal report, non una copia cifrata: non esiste un’operazione di decifratura che ne restituisca il contenuto. Chi possiede il report può ricalcolarne l’hash sul proprio computer e confrontarlo con la prova firmata, senza inviare il report a Mparanza. Mparanza non riceve nomi dei clienti né una corrispondenza fra hash e persone. La riservatezza dei documenti è tutelata escludendone i contenuti dalla richiesta; l’invio automatico crea la ricevuta tecnica.

Il normale funzionamento dei plugin non invia né conserva sul server di Mparanza LLC i dati del cliente o del lavoro. Per il normale funzionamento dei plugin non è quindi necessario un DPA con Mparanza LLC.

Alcune elaborazioni particolari, richieste espressamente, possono utilizzare il server di Mparanza LLC. La documentazione della funzione indica quali dati vengono inviati e come sono trattati.