Claude per uno studio legale, conforme by design

Gli avvocati volevano usare Claude. Il problema non era il modello, era tutto quello che gli sta intorno: dove passano i dati, chi li vede, per quanto restano, chi ha fatto cosa. Abbiamo costruito un perimetro in cui la risposta a ognuna di queste domande è scritta nella configurazione, non in una promessa.

Il cliente

Un'associazione professionale tra avvocati (nome riservato) che segue diritto civile, commerciale e del lavoro, con soci, collaboratori, praticanti e personale di segreteria che lavorano ogni giorno su atti, contratti, pareri e corrispondenza con i clienti.

Materiale che contiene, per definizione, il tipo di dato più delicato che esista in uno studio: informazioni coperte da segreto professionale, dati personali di clienti e controparti, spesso dati relativi alla salute (cause di risarcimento, lavoro) e dati giudiziari.

La richiesta

Lo studio aveva un problema molto comune: l'AI era già entrata, ma dalla porta sbagliata. Alcuni professionisti usavano chatbot con account personali, incollando estratti di atti e contratti. Nessun contratto sul trattamento dei dati tra lo studio e il fornitore, nessun controllo su dove finissero quei testi, nessuna possibilità di revocare l'accesso quando un collaboratore lasciava lo studio, nessuna traccia di cosa fosse stato condiviso.

Vietarlo non funzionava: il vantaggio sulla stesura di bozze, sulla sintesi di fascicoli e sulla revisione contrattuale era troppo evidente. La richiesta dello studio è stata quindi netta: dare a tutti Claude, ma dentro un perimetro in cui ogni obbligo di legge sia soddisfatto e dimostrabile.

I requisiti, messi nero su bianco con i soci e con il DPO:

• nessun dato dei clienti conservato dal fornitore del modello, né usato per addestrarlo;
• elaborazione solo nell'Unione Europea;
• ogni utente identificato individualmente, nessuna credenziale condivisa;
• minimizzazione dei dati personali prima che arrivino al modello;
• separazione tra pratiche, per rispettare conflitti di interesse e riservatezza interna;
• tracciabilità di chi usa il sistema, senza creare un nuovo archivio di contenuti riservati;
• documentazione sufficiente per DPIA, registro dei trattamenti e informativa ai clienti.

Perché AWS Bedrock

Abbiamo scelto di erogare Claude tramite Amazon Bedrock per quattro motivi concreti:

1. Il contratto è già quello giusto. Il trattamento è coperto dal Data Processing Addendum di AWS (integrato nei Service Terms, con clausole contrattuali standard), e AWS mette a disposizione tramite AWS Artifact le certificazioni ISO 27001, 27017, 27018, 27701 e i report SOC che servono per la DPIA.
2. Bedrock non conserva prompt e risposte. Per come è progettato il servizio, i contenuti delle richieste non vengono salvati né usati per addestrare modelli, e Anthropic, come fornitore del modello, non ha accesso a prompt e risposte.
3. Region europee. L'inferenza si può vincolare a data center nell'Unione Europea.
4. Tutti i controlli nello stesso posto. Identità, rete privata, cifratura con chiavi proprie, audit e policy di organizzazione sono servizi AWS nativi, configurabili come codice e verificabili in qualsiasi momento.

Il resto del lavoro è stato trasformare queste premesse in una configurazione blindata, perché un servizio conforme usato male resta un trattamento non conforme.

L'architettura in sintesi

Livello	Scelta	Obiettivo
Modello	Claude su Amazon Bedrock, profili di inferenza eu.	Nessuna conservazione, elaborazione in UE
Identità	IAM Identity Center federato con l'identity provider dello studio, MFA	Account individuali, revoca centralizzata
Minimizzazione	Livello di pseudonimizzazione + Bedrock Guardrails	Il modello vede il meno possibile
Rete	VPC endpoint privati (PrivateLink), nessun accesso pubblico	Il traffico non attraversa internet
Cifratura	AWS KMS con chiavi gestite dallo studio	Controllo delle chiavi su tutti i dati a riposo
Documenti	Bedrock Knowledge Bases con filtri per pratica	Muri etici tra fascicoli
Audit	CloudTrail immutabile + audit applicativo di soli metadati	Chi, quando, cosa, mai il contenuto
Governance	AWS Organizations, SCP, AWS Config, infrastruttura come codice	Nessuno può disattivare i controlli

1. Zero data retention: cosa succede davvero ai dati

"Zero retention" è una promessa che si rompe facilmente. Non basta che il modello non conservi nulla: bisogna chiudere ogni punto della catena in cui un testo potrebbe restare scritto da qualche parte.

• Lato Bedrock. Prompt e risposte vengono elaborati e non salvati dal servizio, non addestrano alcun modello e non sono accessibili al fornitore del modello.
• Model invocation logging disattivato. Bedrock permette di registrare per intero prompt e risposte su CloudWatch o S3. È utile in sviluppo, pericoloso in produzione. Lo abbiamo spento e abbiamo vietato di riattivarlo con una Service Control Policy: nemmeno un amministratore dell'account può farlo.
• Prompt caching. La cache dei prompt di Bedrock è temporanea (minuti) e non persistente: riduce costi e latenza sui documenti lunghi senza creare un archivio.
• Nessuna cronologia di default nell'applicazione. Le conversazioni vivono nella sessione. Salvarle è una scelta esplicita dell'utente, legata a una pratica, cifrata e con cancellazione automatica a scadenza (TTL) secondo il periodo fissato nella DPIA.
• Nessun contenuto nei log applicativi. I log del backend sono filtrati: registrano identificativi tecnici, tempi e codici di errore, mai il testo. Tutti i log group hanno una retention impostata, niente "conserva per sempre".
• Nessun dato nel browser. L'interfaccia non salva conversazioni in localStorage o in cache del browser, così un portatile lasciato aperto o condiviso non diventa un archivio.
• Funzioni che portano dati fuori perimetro disabilitate. Niente ricerca web, niente tool che chiamano servizi esterni, niente modelli di terze parti del marketplace, niente fine-tuning (che richiederebbe di conservare dati di addestramento).

2. Residenza dei dati: tutto nell'Unione Europea

• Region europee. L'account lavora da una region UE. Claude viene invocato tramite profili di inferenza cross-region eu., che distribuiscono il carico solo tra region europee.
• Profili globali vietati. I profili global. possono instradare le richieste in qualsiasi region del mondo: sono bloccati a livello di organizzazione.
• Region non europee bloccate. Una SCP nega qualsiasi operazione fuori dalle region UE (con le sole eccezioni tecniche dei servizi globali come IAM).
• Tutto il resto segue. Bucket S3 dei documenti, indice vettoriale, chiavi KMS, trail di audit e backup stanno nelle stesse region europee.

Un estratto delle policy di organizzazione applicate all'account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalInferenceProfiles",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:*:*:inference-profile/global.*"
    },
    {
      "Sid": "DenyInvocationLoggingChanges",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutModelInvocationLoggingConfiguration",
        "bedrock:DeleteModelInvocationLoggingConfiguration"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBedrockApiKeys",
      "Effect": "Deny",
      "Action": ["iam:CreateServiceSpecificCredential", "bedrock:CallWithBearerToken"],
      "Resource": "*"
    }
  ]
}

3. Account individuali, nessuna chiave condivisa

L'errore più comune nei progetti AI aziendali è una sola chiave API incollata in un file di configurazione e usata da tutti. In uno studio legale significa non sapere chi ha inviato cosa, e non poter togliere l'accesso a una persona senza toglierlo a tutte.

• Single sign-on con l'identity provider dello studio. Gli utenti entrano con le stesse credenziali che usano per posta e documenti, tramite IAM Identity Center federato. MFA obbligatoria.
• Provisioning automatico (SCIM). Quando un collaboratore lascia lo studio, lo si disattiva in un solo punto e perde l'accesso ovunque, nello stesso momento.
• Nessun utente IAM, nessuna access key permanente. Solo credenziali temporanee. La creazione di utenti IAM, di access key e delle API key di Bedrock è vietata via SCP.
• Permessi per ruolo. Soci, avvocati, praticanti e segreteria hanno profili diversi: quali modelli possono usare, quali raccolte documentali possono interrogare, chi può salvare conversazioni.
• Minimo privilegio anche per l'applicazione. Il backend può invocare solo i modelli e i profili di inferenza approvati, e solo con il guardrail dello studio applicato.
• Account root messo in sicurezza. MFA hardware, nessun uso operativo, procedura di accesso di emergenza documentata.

4. Dati personali e segreto professionale: minimizzare prima del modello

Il dato più sicuro è quello che il modello non riceve mai. Per la maggior parte dei compiti (riassumere un contratto, verificare una clausola, impostare una memoria) il modello non ha bisogno di sapere come si chiama il cliente.

Pseudonimizzazione reversibile. Prima di ogni chiamata, un livello applicativo che gira nell'account dello studio sostituisce gli identificativi con segnaposto coerenti: [PERSONA_1], [SOCIETA_2], [CF_1]. Nomi, codici fiscali, partite IVA, IBAN, email, telefoni, indirizzi, targhe, numeri di ruolo generale. La tabella di corrispondenza resta solo in memoria per la durata della richiesta e serve a ricomporre la risposta: l'avvocato legge il testo con i nomi veri, il modello non li ha mai visti.

Quando un compito richiede davvero i dati reali (per esempio la stesura finale di un atto), l'utente può disattivare la pseudonimizzazione per quella richiesta: la scelta è consapevole e registrata nell'audit.

Bedrock Guardrails come seconda linea. Sopra la pseudonimizzazione, un guardrail applicato sia all'input sia all'output:

• filtri sui dati sensibili con mascheramento o blocco dei tipi di PII riconosciuti;
• espressioni regolari personalizzate per i formati italiani, dove il riconoscimento automatico generico è meno affidabile: codice fiscale, partita IVA, IBAN italiano, numeri di RG;
• filtro contro prompt attack, importante perché gli utenti caricano documenti di terzi che potrebbero contenere istruzioni nascoste (prompt injection);
• controllo di grounding sulle risposte basate sui documenti dello studio, per ridurre le risposte non supportate dalle fonti.

Il guardrail non è facoltativo: la policy IAM nega qualsiasi invocazione del modello che non includa il guardrail dello studio, tramite la condition key bedrock:GuardrailIdentifier.

Un esempio del pattern usato per il codice fiscale:

\b[A-Z]{6}[0-9LMNPQRSTUV]{2}[ABCDEHLMPRST][0-9LMNPQRSTUV]{2}[A-Z][0-9LMNPQRSTUV]{3}[A-Z]\b

Categorie particolari e dati giudiziari. I trattamenti che coinvolgono dati sanitari (art. 9 GDPR) e dati relativi a reati e condanne (art. 10 GDPR) sono stati mappati a parte nella DPIA, con regole d'uso specifiche.

5. Rete privata e cifratura

• Nessun passaggio su internet. Le chiamate a Bedrock, S3 e KMS passano da VPC interface endpoint (AWS PrivateLink). L'applicazione gira in subnet private.
• Credenziali inutili fuori dal perimetro. Le policy consentono di invocare Bedrock solo attraverso l'endpoint privato dello studio (condizione aws:SourceVpce): anche una credenziale rubata non funziona da fuori.
• Cifratura in transito con TLS 1.2 o superiore, con richieste non cifrate rifiutate a livello di bucket (aws:SecureTransport).
• Cifratura a riposo con chiavi dello studio. Documenti, indice vettoriale, conversazioni salvate, log e trail sono cifrati con chiavi KMS gestite dal cliente, con rotazione automatica e key policy che separano chi amministra le chiavi da chi le usa. Revocare una chiave rende illeggibili i dati.
• Blocco dell'accesso pubblico attivo a livello di account su tutti i bucket S3.
• Opzione External Key Store. Per i requisiti più stringenti l'architettura è predisposta per tenere le chiavi su un HSM esterno ad AWS (XKS), valutato nella analisi dei trasferimenti.

6. Documenti dello studio e muri etici

Il valore vero arriva quando Claude può lavorare sui documenti dello studio: modelli di atti, pareri precedenti, contratti tipo, giurisprudenza raccolta negli anni.

• Bedrock Knowledge Bases su bucket S3 in UE, con modello di embedding multilingua eseguito su Bedrock in UE e indice vettoriale cifrato.
• Metadati su ogni documento: pratica, cliente, team assegnato, livello di riservatezza.
• Muri etici applicati lato server. Ogni ricerca è filtrata in base ai gruppi dell'utente letti dall'identità SSO, non dal testo della domanda. Un avvocato non assegnato a una pratica non può recuperarne i documenti, nemmeno chiedendolo esplicitamente. È lo stesso principio con cui lo studio gestisce conflitti di interesse e riservatezza interna, portato nel sistema AI.
• Fonti citate in ogni risposta, con link al documento originale, così la verifica è immediata.
• Cancellazione coerente. Quando un documento viene eliminato o un fascicolo archiviato, la sincronizzazione lo rimuove anche dall'indice. Le regole di conservazione seguono quelle del fascicolo.

7. Tracciabilità senza archiviare i contenuti

Serve poter rispondere a "chi ha usato il sistema, quando e su quale pratica" senza creare un secondo archivio di dati riservati.

• AWS CloudTrail a livello di organizzazione, su tutte le region, con validazione dell'integrità dei file e salvataggio in un account di log separato su bucket con Object Lock (non modificabile né cancellabile per il periodo definito).
• Audit applicativo di soli metadati: utente, orario, modello, pratica, numero di token, eventuale intervento del guardrail (il tipo, non il testo), disattivazione della pseudonimizzazione.
• Controllo continuo della configurazione con AWS Config, Security Hub e GuardDuty: se qualcuno prova ad attivare il logging dei contenuti, creare una chiave permanente, disattivare CloudTrail o aprire un bucket, parte un alert.
• Costi attribuiti per area tramite application inference profile con tag, utili anche per capire chi usa davvero lo strumento.

8. Governance dell'account e ruolo di Rayo

• AWS Organizations con account separati per carico di lavoro AI, log e sicurezza: chi amministra l'applicazione non può toccare i log di audit.
• L'account è dello studio. Rayo opera tramite un ruolo cross-account con accesso a tempo, approvato e tracciato. Rayo non ha accesso ai contenuti delle conversazioni né ai documenti.
• Rayo come responsabile del trattamento con contratto ex art. 28 GDPR, per le sole attività di gestione tecnica.
• Infrastruttura come codice. Tutta la configurazione è versionata e revisionabile: ogni modifica ha un autore, una data e un motivo, e l'ambiente si può ricostruire identico.
• Budget e quote con soglie di allarme, per evitare sorprese in fattura e individuare usi anomali.

9. Il quadro normativo, punto per punto

Norma	Obbligo	Come è coperto
GDPR art. 5 e 25	Minimizzazione, privacy by design e by default	Pseudonimizzazione, zero retention, cronologia disattivata di default
GDPR art. 28	Contratto con i responsabili	DPA di AWS, contratto art. 28 con Rayo
GDPR art. 30	Registro dei trattamenti	Voce dedicata per l'assistente AI, con finalità, categorie di dati e misure
GDPR art. 32	Sicurezza del trattamento	Cifratura, MFA, minimo privilegio, rete privata, monitoraggio
GDPR art. 33 e 34	Gestione dei data breach	Alert automatici e procedura di notifica entro 72 ore
GDPR art. 35	Valutazione d'impatto	DPIA completa, con le misure tecniche documentate
GDPR art. 9 e 10	Dati sanitari e giudiziari	Regole d'uso dedicate e controlli rafforzati
GDPR capo V	Trasferimenti extra UE	Elaborazione in UE, Data Privacy Framework e clausole standard, valutazione d'impatto del trasferimento
Codice deontologico forense, art. 28	Riserbo e segreto professionale	Perimetro chiuso, muri etici tra pratiche, nessun accesso del fornitore del modello
Legge 132/2025, art. 13	Uso dell'AI nelle professioni intellettuali solo a supporto e informazione al cliente	Output sempre marcati come bozza, clausola nel mandato professionale, informativa ai clienti
AI Act, art. 4	Alfabetizzazione in materia di AI	Formazione obbligatoria per tutti gli utenti prima dell'attivazione
AI Act, classificazione	Verifica del livello di rischio	Uso di supporto documentato come non ad alto rischio, rivalutato a ogni nuovo caso d'uso

10. Quello che la tecnologia non può fare da sola

Una configurazione perfetta non basta se chi la usa non sa cosa sta facendo. Il progetto ha incluso:

• Policy d'uso interna: cosa si può inserire, quando disattivare la pseudonimizzazione, come verificare le fonti, cosa non delegare mai.
• Formazione per soci, collaboratori, praticanti e segreteria: allucinazioni, verifica delle citazioni, rischi di prompt injection nei documenti di terzi.
• Supervisione umana obbligatoria. Ogni output è una bozza. La firma e la responsabilità restano dell'avvocato, come previsto dalla legge.
• Informativa ai clienti e clausola nel mandato professionale che spiega in modo semplice quali strumenti di AI vengono usati e con quali garanzie.
• Revisione periodica della configurazione e della DPIA a ogni nuovo modello o nuova funzionalità.

La checklist completa

Tutto quello che abbiamo verificato prima di dare accesso al primo utente:

Dati e conservazione

• Model invocation logging disattivato e bloccato via SCP
• Nessuna cronologia di default, TTL sulle conversazioni salvate
• Log applicativi senza contenuti, retention impostata su ogni log group
• Nessun dato salvato nel browser
• Ricerca web, tool esterni, marketplace e fine-tuning disabilitati

Residenza

• Solo profili di inferenza eu., profili global. vietati
• SCP che nega le region fuori UE
• S3, indice vettoriale, KMS, log e backup in UE

Identità

• SSO con l'identity provider dello studio e MFA obbligatoria
• Provisioning e deprovisioning automatici via SCIM
• Nessun utente IAM, nessuna access key permanente, API key Bedrock vietate
• Permessi per ruolo e minimo privilegio sull'applicazione
• Account root protetto con MFA hardware

Minimizzazione

• Pseudonimizzazione reversibile prima del modello
• Guardrail obbligatorio su input e output, imposto via IAM
• Pattern personalizzati per codice fiscale, partita IVA, IBAN e numeri di RG
• Filtro prompt attack e controllo di grounding

Rete e cifratura

• PrivateLink per Bedrock, S3 e KMS
• Invocazione consentita solo dall'endpoint privato
• TLS obbligatorio, accesso pubblico S3 bloccato
• Chiavi KMS gestite dallo studio con rotazione automatica

Documenti

• Metadati per pratica, cliente, team e riservatezza
• Filtri di accesso lato server basati sull'identità SSO
• Citazione delle fonti e cancellazione sincronizzata

Audit e governance

• CloudTrail di organizzazione con Object Lock in account separato
• Audit applicativo di soli metadati
• AWS Config, Security Hub e GuardDuty con alert
• Infrastruttura come codice, budget e quote
• Accesso di Rayo a tempo, tracciato e senza visibilità sui contenuti

Documentazione e persone

• DPIA, registro dei trattamenti, analisi dei trasferimenti
• Contratto art. 28 con Rayo
• Policy d'uso interna e formazione ex art. 4 AI Act
• Informativa ai clienti e clausola nel mandato

Risultati

• Stop all'AI "ombra". Gli account personali sono stati dismessi: tutto lo studio usa un unico strumento, sotto il controllo dello studio.
• Conformità dimostrabile. Per ogni obbligo esiste una configurazione precisa, verificabile e documentata nella DPIA. Se il Garante o un cliente chiede "dove vanno i miei dati?", la risposta è una pagina, non una rassicurazione.
• Nessun nuovo archivio di dati riservati. Il sistema produce bozze, sintesi e revisioni, e non trattiene nulla oltre a quanto deciso dallo studio.
• Revoca istantanea. Un collaboratore che esce perde l'accesso nello stesso momento in cui viene disattivato l'account aziendale.
• Controlli che non si possono aggirare. Le protezioni più importanti sono imposte a livello di organizzazione: non dipendono dalla buona volontà di chi amministra l'account.

Stack tecnologico

Ambito	Tecnologie
Modello	Claude su Amazon Bedrock (profili di inferenza UE)
Identità	AWS IAM Identity Center, SSO federato, SCIM, MFA
Protezione dati	Livello di pseudonimizzazione custom, Amazon Bedrock Guardrails
Documenti	Amazon Bedrock Knowledge Bases, Amazon S3, indice vettoriale cifrato
Rete	Amazon VPC, AWS PrivateLink
Cifratura	AWS KMS con chiavi gestite dal cliente
Audit e sicurezza	AWS CloudTrail, S3 Object Lock, AWS Config, Security Hub, GuardDuty
Governance	AWS Organizations, Service Control Policies, infrastruttura come codice

In sintesi

Usare Claude in uno studio legale in modo conforme non richiede di rinunciare al modello migliore, richiede di costruirgli intorno il perimetro giusto. Zero conservazione, dati in UE, identità individuali, minimizzazione, cifratura con chiavi proprie, muri etici e audit: ognuno di questi punti, da solo, non basta. Tutti insieme trasformano un'AI potente in uno strumento che uno studio può usare sui fascicoli veri, e difendere davanti a chiunque chieda conto.