Nonostante la protezione del dato e la cultura della sicurezza delle informazioni abbiano compiuto dei significativi passi in avanti negli ultimi anni, ancora oggi, molte piccole-medie imprese trovano difficoltà nell’implementare modelli di gestione della privacy anche basilari.

Molti continuano, ingiustamente, ad avere paura delle sanzioni previste dal Regolamento Europeo con l’effetto di produrre inutile carta senza aumentare il livello di consapevolezza, accountability e sicurezza. Da qui si producono inutili consensi controfirmati, lettere di incarico senza formare le risorse e burocratizzazione inutile di processi che potrebbero essere lineari, semplici e paperless.

Non penso sia un caso, dunque, che la protezione del dato continui erroneamente ad essere abbinata a burocrazia inutile quando essa potrebbe essere agevolmente gestita con pochi essenziali adempimenti.

Non me ne voglia chi ci ha prosperato con la paura delle salatissime multe e prodotto carta inutile; ma molte volte, per raggiungere un grado sufficiente di compliance, è sufficiente dotarsi di pochi piccoli accorgimenti ed effettuare pochi piccoli investimenti mirati, principalmente in misure di sicurezza e formazione delle risorse umane.

Sperando di ripetere l’ovvio, ribadisco che la “paperless compliance for free… almost” non può trovare applicazione, ad esempio, per realtà molto particolari che effettuano trattamenti ad alto rischio, anche se poco strutturate così come per realtà che trattano dati su larga scala o presentano rischi maggiori rispetto alla media.

Per affrontare il discorso relativo alla paperless compliance, è necessario tenere presente che il GDPR va letto partendo dall’articolo 1 per poi scorrere verso gli articoli finali abbinando, se possibile, la lettura dei considerando alla norma.

È oramai opinione consolidata fra gli esperti che il GDPR chiede di affrontare con un approccio organico tutti i processi aziendali dove vengono coinvolti dati personali.

Ogni processo deve, dunque, essere originariamente configurato per garantire il rispetto principi generali previsti dall’art. 5: liceità, correttezza e trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza e responsabilizzazione (o accountability per gli anglofili).  Non ci dilungheremo in questa sede su questi principi, limitandoci a citarli.

In secondo luogo, bisogna vedere se ricorre una o più delle basi di legittimità previste dal susseguente art. 6, fra cui è presente anche il consenso dell’interessato che però, è bene richiedere solo ove strettamente necessario (v. https://avvgiacomoconti.com/un-consenso-per-uno-e-uno-per-tutti-una-corretta-applicazione-del-principio-di-irresponsabilizzazione/ ).

Se l’organizzazione sa perché tratta il dato e partendo da quali basi, ad esempio un contratto o una norma di legge o un legittimo interesse, potrà approfondire la conformità del processo al GDPR, ma potrà con una certa ragionevolezza essere sicura che il processo è, in linea di massima, lecito.

Sorvolando sugli articoli seguenti ci troviamo all’art. 24 che menziona espressamente i rischi per i diritti e per le libertà degli interessati che sono indicati per sommi capi nel testo dell’articolo. La norma, senza richiedere nulla di trascendentale chiede semplicemente di tenere conto dei trattamenti che vengono operati all’interno dell’organizzazione e di adottare misure organizzative e di sicurezza adeguate e parametrate al rischio.

Senza pretesa di esaustività, basti pensare al fatto che il trattamento di dati personali apre una finestra sulla vita dell’interessato e a seconda del “peso specifico” del dato personale sarò in grado di conoscere certi aspetti della vita di una persona che sarà, conseguentemente, vulnerabile. Per questa ragione il GDPR distingue i dati in comuni (che permettono di identificare o prendere contatto con l’interessato) e particolari (che invece rilevano aspetti particolarmente delicati della vita privata altrui).  È bene abbinare la lettura dell’art. 24 agli artt. 9 e 10 del GDPR per meglio comprendere il concetto di “rischi per i diritti e per le libertà”.

Semplificando al massimo questo processo che è piuttosto complesso, è essenziale che ogni organizzazione sappia almeno in linea di massima quali dati tratta, per quale motivo e che effetto una violazione alla loro riservatezza, integrità e disponibilità può avere sulla vita personale del lavoratore, del cliente del fornitore e degli altri soggetti coinvolti nel trattamento.

Veniamo ora all’art. 29 che richiede di adottare misure organizzative adeguate. In questa sede ci limiteremo ad indicare le misure che ogni impresa dovrebbe adottare fra le quali, l’individuazione del designato/privacy officer che è un soggetto interno incaricato della gestione delle procedure di trattamento dei dati e per rispettare il GDPR, come garantire le richieste degli interessati o comunicare con l’autorità garante.

Questa figura dovrebbe essere interessata alla materia, adeguatamente formata e responsabilizzata per assicurare un adeguato livello di compliance interno all’organizzazione. L’attività di designazione del referente privacy è un processo a costo zero. Altrettanto gratuita potrebbe essere la creazione dell’organigramma aziendale dove vengono mappati funzioni e compiti dei soggetti designati dall’organizzazione.

Se si vuole che la designazione sia efficiente, tuttavia, sarebbe bene stanziare una somma – anche modesta – per la formazione dei referenti affinché questi siano in grado di mappare e gestire le procedure di cui sono incaricati e responsabilizzare anche gli altri soggetti autorizzati al trattamento.

Veniamo a questo punto ai registri disciplinati dall’art.30: questi altro non sono che un processo di mappatura dei trattamenti che l’azienda opera. Pertanto, i registri dovrebbero configurarsi più che come un documento, come una procedura da monitorare e tenere aggiornata con l’evolversi dei processi aziendali. Pertanto, essi possono essere tenuti senza particolari formalità e aggiornati, anche mediante stampa del file anche in PDF, all’occorrenza.

Più che la forma, è importante che questi strumenti siano tenuti da un soggetto competente che, verosimilmente, sarà il designato aziendale che conoscerà i processi aziendali ed avrà anche una discreta conoscenza normativa ove adeguatamente formato.

Oltre al registro delle attività di trattamento (art. 30), è opportuno che l’organizzazione si munisca anche di un registro della formazione per documentare l’attività svolta e un registro delle violazioni (art. 33) per documentare eventuali data breach e che è uno strumento di ausilio e responsabilizzazione fondamentale per valutare se e quali conseguenze la violazione potrà avere per gli interessati coinvolti.

Seppure i registri non siano richiesti a tutte le organizzazioni, l’adozione di questi è stata fortemente incoraggiata sia dalla nostra Autorità Garante che dal Comitato Europeo per la protezione dei dati personali, ma anche da autorità straniere.

Veniamo ora ai processi relativi alla sicurezza dei dati che possono avere natura fisica o logica.

La sicurezza fisica si articola in misure piuttosto banali come, ad esempio, l’apposizione di porte blindate agli ingressi, inferriate alle finestre, la presenza di estintori.

Apparentemente più complesso è il profilo della sicurezza informatica, ma anche qui, vedremo soluzioni a basso costo o gratuite che possono aiutare enormemente l’organizzazione ad aumentare il proprio livello di sicurezza.

Il primo problema comune a tutte le organizzazioni è la gestione delle Password. Avere password in giro non protette è come lasciare le chiavi della porta vicino allo zerbino di casa.

Rinviando all’apprezzabile vademecum elaborato dal Garante (v. https://www.garanteprivacy.it/temi/cybersecurity/password) è consigliabile adottare gestionali gratuiti come KeePass ( v. https://keepass.info/ ) che salvano i dati in locale criptati eliminando il rischio del cloud e attraverso la master password e i plugin consentono un’agile gestione delle password eliminando fogliettini, il rischio di perderle e altri rischi. Il dipendente dovrà ricordarsi solo la Master Password di accesso al servizio KeePass per accedere in sicurezza a tutte le proprie credenziali.

Altro problema che ogni organizzazione affronta è il backup e, per le organizzazioni più semplici, può bastare anche un piccolo investimento in un NAS o in un economico servizio di backup online scegliendo quello più adatto alle proprie esigenze. Senza dilungarci sulla gestione della backup policy in questa sede, si segnala Duplicati (v. https://www.duplicati.com/ ): una soluzione che rende più efficiente il processo di backup e aiuta a gestire il rischio di perdita dei dati trattati. Questo sistema, di default cripta i dati in formato criptato e permette di gestire la recovery dei dati in maniera intuitiva e semplice. Il gestionale è anche flessibile e permette all’utente di configurare i tempi, modi e livelli di sicurezza del backup.

Potrebbe essere auspicabile anche prevedere un programma formativo con oggetto la cybersecuirty awareness per sensibilizzare i dipendenti alle minacce informatiche. Per iniziare il percorso di sensibilizzazione si può iniziare con il fruire di risorse gratuite e accessibili online.

I problemi della sicurezza informatica, ça va sans dire, non si esauriscono a quelli indicati ed è auspicabile che buona parte delle organizzazioni si accerti, fra le altre cose, di:

  1. Installare solamente programmi originali da autori verificati e sempre aggiornati all’ultima versione
  2. Investire in un solido antivirus che implementi almeno un firewall logico e sistemi di rimozione di malware
  3. Differenziare la rete ad uso interna da quella data ad uso degli ospiti adottando processi di segmentazione

I più scrupolosi vorranno, altresì, adottare un firewall perimetrale integrato con un servizio di analisi dei file di log.

Pare, dunque, opportuno stanziare somme, anche modeste, per aumentare il proprio livello di sicurezza informatica in azienda investendo sulle risorse umane e sulle misure di protezione tecniche.

Un’azienda con un elevato grado di compliance al GDPR, dunque, saprà valutare in autonomia gli investimenti, a livello tecnico e sulle risorse umane, che dovrà operare e saprà gestirsi autonomamente evitando di spendere soldi in consulenze inutili e carte e agire in autonomia per rispettare la norma, nelle migliori ipotesi, con un costo tendente allo zero o con un investimento più che contenuto.

Il GDPR non richiede, dunque, di produrre carte, ma di implementare dei processi efficienti per una corretta gestione del dato e, per essere applicato efficacemente, richiede cultura, formazione e sensibilizzazione.

di Giacomo Conti

 

Sempre più sovente le pubbliche amministrazioni, al pari degli operatori di diritto privato adottano modelli predittivi automatizzati applicando criteri prestabiliti per raccogliere, selezionare, ordinare processare e strutturare i dati.

Nell’ambito dell’azione delle PA, l’utilizzo di suddetti strumenti è dettato da logiche di efficienza ed economicità dell’azione amministrativa (art. 1 l. 241/90) che, secondo il principio costituzionale di buon andamento dell’azione amministrativa (art. 97 Cost.), impongono all’amministrazione il conseguimento dei propri fini con il minor dispendio di mezzi e risorse e attraverso lo snellimento e l’accelerazione dell’iter procedimentale.

L’automatizzazione dei processi minimizza il rischio di errori da un lato e permette di ridurre il costo del personale.

Lungi dall’essere una mera applicazione meccanica di protocolli, questi modelli spesso sono anche in grado di interpretare e formulare giudizi valoriali e arrivano ad incidere sulla sfera personale di persone fisiche e giuridiche che si trovano coinvolte in processi automatizzati. Pertanto, gli algoritmi vengono sfruttati nell’ambito di procedure seriali o standardizzate che richiedono l’elaborazione di ingenti quantità di istanze e caratterizzate dall’acquisizione di dati certi ed oggettivamente comprovabili e dall’assenza di ogni apprezzamento discrezionale.

In certi contesti sono proprio questi algoritmi, infatti, ad operare le scelte e ad applicare, spesso in autonomia, i criteri selezionati elaborando i dati di riferimento utilizzati.

L’utilizzo di queste tecnologie, tuttavia, pone significativi problemi di trasparenza, anche con riferimento all’applicazione delle norme in materia di protezione dei dati personali, dove il procedimento amministrativo riguarda persone fisiche. Ad esempio, per la selezione di personale attraverso procedure concorsuali.

In materia di ricorso ad algoritmi per l’adozione di provvedimenti amministrativi, anche alla luce della disciplina di origine sovranazionale, assumono rilievo fondamentale due aspetti preminenti, quali elementi di minima garanzia per ogni ipotesi di utilizzo di algoritmi in sede decisoria pubblica: la piena conoscibilità a monte del modulo utilizzato e dei criteri applicati e l’imputabilità della decisione all’organo titolare del potere, il quale deve poter svolgere la necessaria verifica di logicità e legittimità della scelta e degli esiti affidati all’algoritmo. Secondo una corretta applicazione della Legge 241/90 sul procedimento amministrativo e anche del GDPR[1].

Più specificatamente, è necessario, ai fini dell’ammissibilità del ricorso ad algoritmi informatici nel procedimento di formazione della decisione amministrativa, che vi sia la piena conoscibilità a monte del modulo utilizzato e dei criteri applicati e l’imputabilità della decisione all’organo titolare del potere, il quale deve poter svolgere la necessaria verifica di logicità e legittimità della scelta e degli esiti affidati all’algoritmo. Questi rappresentano, infatti, elementi di garanzia minima per garantire la legittimità del procedimento e del provvedimento finale[2].

Al riguardo, giova richiamare anche la Carta della Robotica, approvata nel febbraio del 2017 dal Parlamento Europeo secondo cui  “l’autonomia di un robot può essere definita come la capacità di prendere decisioni e metterle in atto nel mondo esterno, indipendentemente da un controllo o un’influenza esterna; (…) tale autonomia è di natura puramente tecnologica e il suo livello dipende dal grado di complessità con cui è stata progettata l’interazione di un robot con l’ambiente; (…) nell’ipotesi in cui un robot possa prendere decisioni autonome, le norme tradizionali non sono sufficienti per attivare la responsabilità per i danni causati da un robot, in quanto non consentirebbero di determinare qual è il soggetto cui incombe la responsabilità del risarcimento né di esigere da tale soggetto la riparazione dei danni causati».

Una corretta applicazione dei predetti principi implica, dunque, che lo strumento automatizzato possa soltanto essere un ausilio alla PA procedente e non possa essere un mezzo di valutazione autonoma attraverso cui deresponsabilizzare i referenti del procedimento. Il principio di buon andamento implica, dunque, che vi sia comunque un responsabile umano per le decisioni prese dall’algoritmo.

Le implicazioni legali di questi strumenti, tuttavia, vanno oltre la sfera del buon andamento della pubblica amministrazione, ma riguardano anche diritti fondamentali della personalità, fra cui il diritto alla protezione dei dati personali che assume profili di portata sostanziale e di rilievo anche sovranazionale.

Il Regolamento Generale sulla Protezione dei Dati Personali, infatti, non si limita a dettare una disciplina formale attraverso l’informativa e il diritto di accesso, ma pone un espresso limite allo svolgimento di processi decisionali interamente automatizzati. L’articolo 22, paragrafo 1 GDPR riconosce, infatti, alla persona fisica il diritto di non essere sottoposta a decisioni automatizzate prive di un coinvolgimento umano e che, allo stesso tempo, producano effetti giuridici o incidano in modo analogo sull’individuo. Quindi occorre sempre l’individuazione di un centro di imputazione e di responsabilità, che sia in grado di verificare la legittimità e logicità della decisione dettata dall’algoritmo.

Mutatis mutandis, è facile applicare questa disposizione normativa anche con riferimento alle persone giuridiche – espressamente escluse dall’ambito di applicazione del GDPR – almeno nei confronti della pubblica amministrazione. Non si può negare, infatti, a questi enti una posizione di interesse legittimo al buon andamento della pubblica amministrazione e al diritto ad ottenere un riesame della decisione presa dall’algoritmo laddove la stessa risulti pregiudizievole delle posizioni giuridiche di questi.

 

[1] Cons. Stato Sez. VI, 13/12/2019, n. 8472 Ministero dell’Istruzione dell’Università e della Ricerca e altri c. P.C. a conferma di T.A.R. Lazio Roma, Sez. III, n. 9230/2018.

[2] Cons. Stato Sez. VI, 04/02/2020, n. 881 – Ministero dell’Istruzione dell’Università e della Ricerca c. O.B. e altri a conferma T.A.R. Lazio n. 6607 del 2019.

di Jacopo Sabbadini

Uno degli attacchi più semplici che si possono portare contro un database è sicuramente il cosiddetto SQLInjection, che consiste nel utilizzare il linguaggio SQL per accedere ai dati di un database.
Facciamo un attimo di chiarezza su cosa sia un form e come funzioni a livello di backend del database; in poche parole, il form è l’interfaccia che vede l’utente, in cui inserisce i propri dati (ad esempio nome, cognome, data di nascita, password e via discorrendo) al momento della registrazione su un sito, o al momento del login sul sito stesso. Questi dati inseriti dall’utente vengono trattati dal database ed inseriti all’interno dello stesso, utilizzando la sintassi propria del database in esame (nel nostro caso SQL per un database scritto in MySQL).
Appare immediatamente evidente un problema: come fa la macchina a distinguere nel momento in cui viene digitata una stringa nel campo del form, tra una stringa che deve inserire all’interno del database (ad esempio il nome) e un comando nel proprio linguaggio?
Qui è necessaria la corretta configurazione del form, vi sono vari tools che permettono di filtrare quanto viene scritto dall’utente, in modo tale che qualsiasi cosa scriva non verrà mai interpretata come un comando.
Se questa precauzione però non viene presa, si rende l’intero database vulnerabile ad un injection, cioè l’inserimento dall’esterno di un comando.
A titolo dimostrativo useremo una macchina virtuale appositamente costruita con questa vulnerabilità.
Iniziamo con registrare un nuovo utente, lo chiameremo Pippo, password Topolino, signature Paperino

 

Una volta creato il nostro nuovo utente, vediamo come normalmente risponde il database ad una query normale, cioè inserendo i corretti parametri per username e password

 

Come si può vedere, nulla di strano, mi viene restituito a video un riepilogo delle informazioni inserite.
Vediamo però cosa succede se cambiamo leggermente il nostro username, e aggiungiamo un ‘, cioè un apice, alla fine del nome. Se il form fosse correttamente settato, dovrebbe semplicemente restituirci un errore in quanto non esiste nessun utente con lo username Pippo’.

 

 

In realtà ci viene restituita una videata in cui ci dice che il codice che abbiamo inserito contiene un errore, nello specifico: Query: SELECT * FROM accounts WHERE username=’Pippo ” AND password=” (0) [Exception]
Questo ci fa capire che in realtà il form non era correttamente configurato, e il database va in errore in quanto il comando che gli è stato dato non era sintatticamente corretto.
A questo punto, possiamo provare a passare un comando che riconosca come sintatticamente corretto, ad esempio dicendogli di cercare tutti i campi in cui il nome utente sia Pippo, oppure di mostrare a video tutti i campi in cui una condizione che sappiamo essere sempre vera (nell’es 1=1) appaia; questa condizione sarà ovviamente vera per ogni riga del database, e questo è il risultato:

 

Andando in errore il database, stampa a video TUTTE le linee al suo interno, comprensive di username e password. Questa tecnica può essere utilizzata per carpire non solo informazioni dalle tabelle di un database, ma anche per portare ulteriori attacchi al server stesso; la prima linea che ci viene stampata è infatti un utente con username admin e password admin; si potrebbe provare a connettersi direttamente al server usando queste credenziali, per prenderne il controllo, e per iniziare un’escalation di permessi.

Per concludere quindi, sempre controllare che le interfacce utente siano correttamente settate, altrimenti il backend più sicuro al mondo può essere bypassato con estrema semplicità.

di Guglielmo Marchelli

La graduale introduzione del processo civile telematico, fino alla sua definitiva obbligatorietà a decorrere dal 31/12/2014 per tutti i Tribunali e 30/06/2015 per le Corti d’Appello, ha imposto agli operatori del settore l’adozione di specifici programmi per elaboratore, onde effettuare il deposito e l’estrazione, presso gli uffici competenti, degli atti giudiziari in formato elettronico.
Il sistema prevede la creazione di una cd. “busta telematica”, ovvero, di un archivio (*.enc) contenente gli atti (firmati digitalmente dal professionista) che viene crittografato con la chiave pubblica dell’ufficio giudiziario di destinazione ed inviato a mezzo PEC dall’indirizzo mittente del professionista abilitato.
É altresì previsto un sistema di consultazione dei fascicoli di causa da parte del professionista incaricato, ma anche dal cittadino o del soggetto “parte” del giudizio civile, attraverso appositi “Punti di Accesso” che prevedono un sistema di autenticazione basato su certificato rilasciato da appositi certificatori accreditati, normalmente inserito nel dispositivo di firma elettronica.
Svariate critiche si potrebbero muovere al sistema di deposito telematico anzi descritto.
In effetti, per fare un paragone con il passato, sarebbe come dire che l’avvocato (o il CTU), per depositare i propri atti, dovesse ogni volta spedire al Tribunale un plico raccomandato a/r, in luogo di recarsi personalmente in Cancelleria.
È lecito domandarsi se fosse stato più opportuno implementare il deposito degli atti mediante autenticazione sul Punto di Accesso e caricamento diretto dei file (upload) sul server ministeriale, in combinazione con strumenti tecnici di tracciatura (log), tali da consentire la riferibilità del deposito al professionista titolare del dispositivo di autenticazione e l’apposizione della data certa alla busta (es. mediante marcatura temporale della busta).
Si sarebbe potuto così evitare l’inutile consumo di risorse che oggi avviene con lo scambio di messaggi PEC di svariate decine di Megabyte fra professionista e Cancelleria (allo stato il PCT prevede ben 4 ricevute PEC, fra cui la prima che restituisce al mittente l’intero archivio .enc).
Dopo l’introduzione del processo telematico si è potuto assistere al proliferare di programmi per elaboratore più o meno avanzati, sviluppati quasi esclusivamente per il sistemi operativi MS Windows e rilasciati con licenza “closed source”.
Tali applicativi, oltre a non essere multi-piattaforma, vengono distribuiti ad un prezzo molto elevato rispetto alle funzionalità effettivamente offerte.
Molte software house produttrici hanno adottato una strategia commerciale consistente nel “fidelizzare” numerosi utenti mediante la stipula di convenzioni pluriennali con gli ordini professionali, concedendo in un primo momento il proprio software ad un importo “scontato”, per poi alzare notevolmente i prezzi e/o recedere dalla convenzione, onde imporre il proprio prezzo all’utente ormai abituato ad utilizzare quel determinato “prodotto”.
La conservazione e la gestione dei dati mediante questi programmi avviene, molto spesso, mediante formati proprietari sviluppati dalla stessa software house, con evidente rischio per la portabilità dei dati stessi (anche personali), qualora il professionista volesse migrare verso altri applicativi (cd. “lock-in”).
Certamente, non è questa la sede per sindacare la liceità o l’eticità di tali strategie commerciali (Mi limito ad osservare che l’Antitrust nel 2016 ha aperto un’istruttoria tesa ad “accertare eventuali condotte abusive che avrebbero riguardato l’intera filiera dei sistemi informatici per lo svolgimento di servizi che attengono alla funzione giudiziaria”.).
In verità, parliamo di programmi piuttosto semplici che uniscono gli schemi ministeriali per creazione ed invio telematico delle cd. “buste” a mezzo pec, con il servizio gratuito di consultazione dei fascicoli (il tutto eventualmente condito con un gestionale un po’ datato per l’amministrazione delle pratiche dello studio).
Quello che, tuttavia, è bene chiarire, è che tutti i programmi per elaboratore atti ad effettuare il deposito telematico e/o la consultazione dei fascicoli PCT, non erogano, né potrebbero erogare funzionalità e/o servizi diversi e più avanzati rispetto a quelli messi a disposizione ed implementati sul server ministeriale.
In verità, tutte le operazioni essenziali di deposito e di consultazione e di estrazione atti, possono essere effettuate gratuitamente, con la combinazione di applicativi liberamente reperibili sul web.
La consultazione e l’estrazione di “duplicati” e di copie di atti e provvedimenti dai fascicoli telematici possono essere effettuati, previa autenticazione con il proprio certificato, mediante l’accesso diretto al portale del Ministero, pst.giustizia.it (all’interno del quale sono anche elencati numerosi altri punti di accesso privati e pubblici).
Le funzionalità di deposito telematico possono invece essere effettuate mediante l’installazione dell’applicativo SLPCT (www.slpct.it): un software redattore e creatore di buste completamente gratuito, che opera in combinazione con i più diffusi client di posta elettronica.
Detto software -rilasciato con licenza “open source”- viene costantemente aggiornato con l’evolversi degli schemi ministeriali del PCT ed è liberamente installabile su tutti i computer all’interno del proprio studio.
SLPCT è perfettamente multi-piattaforma poiché è sviluppato per i principali S.O. desktop (Ms Windows, Linux, MacOS).
Non possiamo soffermarci sulla differenza fra “freeware” da un lato e “free software” / “open source” dall’altro (nelle loro svariate e sottili distinzioni), tuttavia, vorrei da ultimo sottolineare che le considerazioni che precedono non sono limitate al PCT ma possono essere estese a tutti gli strumenti software dedicati alle professioni legali.