Benvenuti al podcast su Legal Prompting, sono Nicola Fabiano e questo è l'episodio 6. Nello
scorso episodio abbiamo parlato di chain of thought e few shot prompting, due tecniche che
permettono di guidare il modello attraverso passaggi logici e di mostrargli esempi concreti
del risultato che vogliamo ottenere. Oggi applichiamo quelle tecniche a uno dei terreni
in cui i giuristi lavorano di più, i contratti. Quando parlo di analisi di contratti con l'AI
intendo quattro operazioni distinte. La prima è la revisione strutturata di un singolo contratto,
la seconda è il confronto tra due versioni dello stesso testo, la terza è la verifica di una
clausola rispetto a una checklist, la quarta è l'analisi di un data processing agreement rispetto
all'articolo 28 del GDPR. Sono operazioni diverse e richiedono prompt diversi. Cominciamo dalla
revisione strutturata. L'errore più comune è chiedere al modello rivedi questo contratto. Una
richiesta così generica produce un riassunto, non un'analisi. Il prompt deve invece definire
ruolo, indicare la legge applicabile, fissare il punto di vista da cui leggere il testo ed
elencare le aree da esaminare, per esempio clausole di limitazione di responsabilità,
foro competente, durata e recesso, riservatezza, trattamento dei dati, ipotesi di forza maggiore.
Per ciascuna area chiediamo al modello di citare il testo della clausola, di indicare la criticità
rilevata e di proporre una formulazione alternativa. È chain of thought applicata. Il
modello non emette un giudizio ma percorre un ragionamento che noi possiamo verificare. Il
confronto tra versioni è il caso d'uso in cui l'AI dà i risultati più affidabili. Forniamo le due
versioni, indichiamo che vogliamo le differenze sostanziali e non quelle puramente formali e
chiediamo che ogni differenza sia classificata, a favore di chi è cambiata e quale rischio
introduce. Qui il few shot aiuta molto. Se mostriamo al modello uno o due esempi di come
vogliamo che sia formattata l'analisi delle differenze, l'output diventa subito più utile.
La verifica rispetto a una checklist è terrenominato. Se la checklist è generica,
l'output è generico. Se la checklist è specifica e riflette davvero la nostra prassi professionale,
l'output diventa uno strumento di lavoro. Il punto è che la checklist va costruita prima,
non improvvisata nel prompt. Veniamo al DPA, l'accordo sul trattamento dei dati. Qui il
riferimento è preciso, l'articolo 28 del GDPR elenca i contenuti minimi obbligatori. Possiamo
costruire un prompt che chieda al modello, per ciascuna lettera del paragrafo 3 dell'articolo
28, se la corrispondente previsione è presente nel DPA, dove si trova, e se è formulata in
modo conforme. È un esercizio in cui il modello è effettivamente utile, perché il riferimento
normativo è chiaro e tassativo. Tre cautele. La prima, il modello non negozia. Può segnalare
che una clausola è sbilanciata, ma non sa quanto potere contrattuale abbiamo né quale sia la
prassi del settore. La seconda, il modello non conosce il contesto commerciale. Una clausola
di esclusiva può essere normale in un settore e patologica in un altro. La terza, nessun output
sostituisce la lettura integrale del contratto da parte del professionista. L'AI accelera la prima
passata, non firma al posto nostro. C'è poi un tema che terrà banco nei prossimi episodi, dove
gira il modello che usate per analizzare un contratto del cliente. Caricare un contratto
riservato su un servizio cloud non controllato è una scelta di compliance prima ancora che una
scelta tecnica. Ne parleremo a fondo nell'episodio sul segreto professionale. Nel prossimo episodio
facciamo un passo in avanti dalla revisione del singolo contratto a Legal Prompting come
componente strutturale dei processi di compliance aziendale, come si integra l'AI in un workflow
legale senza creare nuovi rischi e senza disperdere responsabilità. Grazie per l'ascolto.
Appuntamento al prossimo episodio.
Sottotitoli e revisione a cura di QTSS