L'importanza dell’architettura giuridica in un servizio digitale

Quando si parla di compliance di un servizio digitale, l'attenzione tende spesso a concentrarsi sui documenti da predisporre prima del go-live. Sono strumenti necessari, certo, ma descrivono soltanto una parte del problema.

La domanda che si pone, in primo luogo, è: il servizio è stato progettato in modo tale da poter rispettare concretamente le regole che lo riguardano?

Basti pensare, ad esempio, alle implicazioni giuridiche proprie di un servizio come un SaaS: questo rappresenta contemporaneamente un prodotto tecnologico, un modello contrattuale, un'infrastruttura di trattamento dei dati e un rapporto continuativo con i propri utenti. Per questo la sua progettazione dovrebbe essere guidata, fin dall'inizio, da un'architettura giuridica coerente con quella tecnica e con quella commerciale.

Non è raro infatti che, una volta portato il servizio sul mercato, emergano nuove esigenze commerciali o di marketing che richiedano di modificare il modello di business, le funzionalità offerte, le modalità di acquisizione degli utenti o i flussi di utilizzo del servizio. Una diversa strategia di pricing, l’introduzione di nuove funzionalità, l’accesso a nuovi segmenti di clientela o il ricorso a ulteriori fornitori tecnologici possono, dunque, incidere direttamente sull’assetto giuridico del prodotto e rendere parzialmente inadeguata la documentazione predisposta prima del lancio. È anche per questo che l’architettura giuridica dovrebbe essere definita a monte, nonché parallelamente allo sviluppo del progetto; ciò non per cristallizzare il servizio, ma per costruire una struttura sufficientemente coerente e flessibile, da accompagnarne l’evoluzione senza dover ripensare ogni volta, a posteriori, contratti, privacy, responsabilità e compliance.

1. Cosa si intende per “architettura giuridica” di un servizio digitale? L'esempio dei Software as a Service

Per architettura giuridica non si deve intendere semplicemente l'insieme dei documenti legali pubblicati sul sito. La documentazione è piuttosto la formalizzazione di scelte che devono essere state già compiute.

Si prenda ad esempio un servizio SaaS. L'architettura giuridica, per questa tipologia di servizio digitale, può essere vista come l'insieme coordinato di regole, rapporti contrattuali, ruoli, responsabilità, flussi informativi e presidi di compliance necessari affinché il servizio possa essere progettato, offerto, utilizzato, modificato e cessare secondo il modello previsto.

In altri termini, prima di inserire una clausola all'interno di un contratto, occorre avere ben chiaro quale funzione essa assumerà nell'impianto documentale e soprattutto nell'erogazione del servizio.

2. Il diritto non interviene necessariamente dopo la realizzazione del servizio: dovrebbe guidarlo

Una delle ragioni più significative per progettare l'architettura giuridica insieme al servizio vero e proprio, risiede nel fatto che vi sono alcune norme che non impongono soltanto di informare l'utente, ma prescrivono anche come progettare il trattamento e il servizio in un determinato modo.

Ciò è particolarmente evidente nel GDPR, il cui art. 25, ad esempio, richiede al titolare di adottare misure tecniche e organizzative adeguate, già al momento della determinazione dei mezzi del trattamento, integrandone i principi di protezione dei dati. L'art. 32 dello stesso GDPR, poi, collega inoltre la sicurezza del servizio alle caratteristiche e ai rischi del trattamento, prescrivendo l'adozione di misure tecniche e organizzative adeguate.

Questo significa che una valutazione giuridica può guidare direttamente una decisione tecnica.

La logica è quindi diversa da quella della legal review: non si tratta di controllare un prodotto già compiuto, ma di fare in modo che le prescrizioni giuridiche siano prese in considerazione durante la definizione del prodotto.

3. La qualificazione giuridica dei soggetti può cambiare l'architettura

Un SaaS B2B può trattare dati personali per conto dei propri clienti. In questa configurazione, la corretta qualificazione dei ruoli privacy e l'eventuale applicazione dell'art. 28 GDPR non costituiscono una questione meramente documentale.

Se il fornitore agisce come responsabile del trattamento, occorre che il progetto individui istruzioni, sicurezza, gestione dei sub-responsabili e assistenza al titolare. Questo richiede la previa conoscenza di elementi quali provider, API, sistemi di monitoraggio, servizi di posta, strumenti di analytics, sistemi di backup o fornitori AI, che entreranno effettivamente nel perimetro del servizio.

Di conseguenza, la supply chain tecnologica diventa anche una supply chain giuridica: cambiare un provider può comportare la modifica dei flussi di dati, della documentazione contrattuale, delle informative, delle valutazioni, dei trasferimenti e delle misure organizzative.

4. I documenti legali devono descrivere il prodotto reale

L'architettura giuridica dovrebbe essere impostata conoscendo non solo i punti di forza del servizio digitale ma anche i suoi limiti e le eventuali criticità.

Una clausola può prevedere, ad esempio, determinati livelli di disponibilità, una procedura di cancellazione dell'account, la possibilità di esportare i dati o specifici limiti di responsabilità. Ma se l'architettura tecnica non consente di rispettare tali premesse, il documento non risolve i problemi, anzi li aggrava.

Per questo l'impianto documentale e il servizio digitale devono essere progettati in modo coordinato.

Si prenda ad esempio quanto disposto in materia di servizi digitali destinati ai consumatori. La disciplina europea sui contratti per la fornitura di contenuti e servizi digitali, integrando la normativa nazionale del d.lgs. n. 206/2005 - Codice del consumo, collega, tra l'altro, la conformità del servizio a funzionalità, aggiornamenti e sicurezza; per i servizi forniti continuativamente, gli obblighi di aggiornamento possono protrarsi per tutta la durata della fornitura.

Il contratto, quindi, non è soltanto una cornice esterna al software: può essere necessario adeguarlo affinché sia possibile adempiere a quanto pattuito in sede negoziale.

5. Anche l'AI è una scelta strutturale, non soltanto una funzione

Quando un SaaS integra sistemi di intelligenza artificiale, il coinvolgimento del diritto non dovrebbe ridursi all'aggiunta di un disclaimer nella schermata di chat.

Occorre chiedersi che cosa fa esattamente l'AI, quali dati riceve, chi la fornisce, quali output produce, chi li controlla e in quale contesto vengono utilizzati. La risposta può modificare il flusso dei dati, la progettazione dell'interfaccia, le informazioni rivolte all'utente e il rapporto contrattuale.

Il Regolamento (UE) 2024/1689 prevede, tra l'altro, specifici obblighi di trasparenza per determinate categorie di sistemi di AI. L'art. 50 del medesimo stabilisce che i sistemi destinati ad interagire direttamente con persone fisiche debbano essere progettati e sviluppati in modo tale da informare l'interessato che sta interagendo con un sistema di AI, salvo le eccezioni previste; ulteriori obblighi riguardano determinati contenuti generati o manipolati artificialmente.

La domanda, quindi, non è soltanto “quale testo inserire?”, ma anche: in quale punto dell'esperienza utente deve essere resa la trasparenza e come deve funzionare il prodotto per renderla effettiva?

6. L'architettura giuridica serve a distribuire il rischio

Il SaaS non elimina il rischio: lo distribuisce tra fornitore, cliente, utenti e fornitori tecnologici. La progettazione dovrebbe quindi chiarire anticipatamente almeno alcuni snodi fondamentali:

• responsabilità per malfunzionamenti e indisponibilità del servizio;
• SLA, livelli di servizio e rimedi in caso di disservizio;
• responsabilità relativa ai dati e agli accessi;
• gestione degli incidenti e delle violazioni di sicurezza;
• uso consentito degli output e dei contenuti dell'utente;
• modifica o cessazione delle funzionalità e gestione dell'offboarding.

Queste scelte, una volta disciplinate dal contratto, dovranno essere compatibili con il funzionamento reale della piattaforma. Una limitazione di responsabilità non può trasformare una funzione tecnicamente insicura in una funzione sicura; allo stesso modo, uno SLA non può garantire livelli di disponibilità che l'infrastruttura non è progettata per sostenere.

7. Il vantaggio economico della progettazione anticipata

Avere un quadro chiaro, fin dal principio, in merito ai limiti e ai requisiti imposti dalla legge per commercializzare il proprio servizio digitale, rappresenta un vantaggio economico assai rilevante, ben potendo ridurre il costo complessivo del progetto.

Scoprire dopo il lancio che una funzionalità richiede una diversa gestione dei dati, che un provider non è compatibile con il modello di trattamento, che il contratto promette una funzione inesistente o che l'uscita dal servizio non è tecnicamente gestibile, sono solo alcune delle ipotesi che possono imporre procedure complesse di modifica e adeguamento del servizio che spesso mettono in discussione decisioni già prese.

L'obiettivo non è trasformare ogni fase di sviluppo in una disquisizione legale. È costruire, a monte, una architettura delle decisioni giuridicamente rilevanti e individuare quali scelte tecniche o commerciali possono produrre conseguenze normative, contrattuali o di responsabilità.

8. Conclusione

Nella realizzazione e nel perfezionamento di un servizio digitale, l'impianto giuridico non dovrebbe essere considerato come un elemento estraneo, separato, da integrare solo quando tutto il servizio è già stato progettato.

In questo ambito, il diritto e la tecnologia si incontrano proprio nelle scelte che definiscono il servizio: quali dati vengono raccolti, quali funzioni vengono offerte, quali soggetti accedono alle informazioni, quali promesse vengono fatte al cliente, quali responsabilità vengono assunte e cosa accade quando il rapporto termina.

Per questo l'architettura giuridica non è semplicemente un insieme di documenti predisposti per adempiere a delle formalità imposte dal legislatore, ma è una struttura che deve accompagnare il servizio lungo il suo intero ciclo di vita.

Fonti normative