Legal Prompting - Analisi di contratti e clausole con l'AI

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