Quasi 100 pratiche gestite nei primi sei mesi non dimostrano che l’AI sappia fare l’avvocato. Dimostrano qualcosa di più utile: un reparto legale può iniziare dall’intake, dal recupero dei precedenti e dalla preparazione del contesto, lasciando la decisione a chi ne risponde. È il percorso scelto da AT&T con LegalEdge, il centro di competenza avviato nel gennaio 2026 e ora usato come base per una collaborazione con OpenAI.

Per una PMI, il punto non è copiare la scala di AT&T. È copiare l’ordine delle operazioni. Prima si costruisce una porta d’ingresso unica per le richieste, poi si definiscono classificazione, accessi, fonti e responsabilità. Il modello arriva dentro questo processo, non al posto del processo.

Il caso AT&T: prima il flusso, poi il modello

Il dipartimento legale interno di AT&T comprende centinaia di avvocati e professionisti distribuiti nel mondo. Prima di dare un parere devono ricostruire fatti, documenti e lavoro già svolto da altri team. La difficoltà descritta dall’azienda non è quindi solo scrivere una risposta: è rendere disponibile la conoscenza istituzionale quando arriva una nuova richiesta.

AT&T ha annunciato l’8 ottobre 2026 una collaborazione con OpenAI basata su LegalEdge. Secondo la comunicazione ufficiale dell’azienda, LegalEdge aveva gestito quasi 100 pratiche nei primi sei mesi di attività. Il programma coinvolge avvocati, professionisti legali, tecnologi e project manager. Il risultato dichiarato non è un consulente autonomo, ma una capacità riutilizzabile per organizzare il lavoro legale.

Il progetto descritto da OpenAI parte da una «front door» in linguaggio naturale. Una richiesta proveniente dall’azienda entra da un punto controllato; il sistema la classifica e ne propone la priorità; recupera precedenti, ricerche e attività passate; prepara contesto e primi passi per il professionista responsabile. AT&T specifica che le decisioni restano agli avvocati.

Questa distinzione è essenziale. Classificare un ticket, trovare una clausola simile e riassumere tre documenti sono compiti assistivi. Stabilire l’interpretazione corretta, accettare un rischio o approvare una risposta sono decisioni. Se le due categorie finiscono nello stesso prompt, non abbiamo un workflow: abbiamo una delega non misurata.

Perché partire dall’intake

Molte aziende iniziano dall’ultima parte del lavoro: chiedono a un chatbot di produrre il testo finale. È il punto con il rischio più alto e con meno contesto strutturato. L’intake offre invece un perimetro più controllabile. Gli input sono riconoscibili, l’output può avere uno schema fisso e il passaggio a una persona è esplicito.

Un intake utile non è una casella di testo libera collegata a un modello. Deve raccogliere almeno richiedente, reparto, tipo di questione, giurisdizione, scadenza, controparte, livello di riservatezza e documenti allegati. Deve inoltre impedire che un utente invii dati per i quali non possiede l’autorizzazione. Il modello può estrarre e normalizzare queste informazioni, ma l’applicazione deve validarle.

La priorità non può dipendere da un’impressione linguistica. Va calcolata con regole verificabili: una scadenza regolatoria ravvicinata, una richiesta di un’autorità o un possibile data breach devono attivare un percorso definito. Il modello può suggerire l’etichetta; una regola o un revisore confermano l’instradamento.

Questo approccio si collega a un principio che vale anche fuori dall’area legale: nei workflow AI il controllo conta più della sola qualità del testo. Una risposta elegante non compensa una richiesta assegnata al team sbagliato o una fonte non autorizzata.

Un’architettura in sei livelli

La versione adatta a una PMI può essere più piccola di quella di AT&T, ma dovrebbe mantenere sei separazioni tecniche.

  1. Ingresso autenticato. Form, portale o help desk devono identificare l’utente e conservare il consenso operativo. Per un sito WordPress, il form pubblico non dovrebbe interrogare direttamente il modello: invia la richiesta a una coda o a un endpoint server-side protetto.
  2. Normalizzazione. Un primo passaggio estrae i campi necessari, segnala quelli mancanti e genera una sintesi. L’output deve rispettare uno schema JSON, non una risposta in prosa impossibile da validare.
  3. Classificazione. Il sistema assegna materia, urgenza e team. Le classi devono essere poche, definite e collegate a esempi reali. Ogni classificazione conserva versione del prompt, modello, data e livello di confidenza.
  4. Recupero autorizzato. La ricerca consulta solo cartelle, contratti e precedenti accessibili a quel ruolo. Il filtro dei permessi deve avvenire prima del recupero, non dopo la generazione.
  5. Bozza assistita. Il modello prepara una scheda con fatti, fonti recuperate, punti mancanti e possibili passi successivi. Ogni affermazione importante deve rimandare al documento che la sostiene.
  6. Decisione e audit. Una persona approva, corregge o respinge. Il sistema registra l’esito e non trasforma automaticamente una bozza in comunicazione esterna.

La separazione evita che un errore si propaghi senza essere visto. Se il recupero non trova fonti attendibili, il generatore non dovrebbe colmare il vuoto. Se la classificazione ha bassa confidenza, la pratica va in una coda manuale. Se una risposta viene respinta, il motivo diventa un dato per migliorare il processo, non un invito a rendere il prompt più lungo.

Lo stesso schema aiuta a scegliere dove collocare i controlli. Per una verifica periodica, può essere utile confrontare valutazione interna e audit esterno: la prima intercetta regressioni frequenti, il secondo mette alla prova assunzioni che il team potrebbe non vedere.

Il pilota in 30 giorni

Un pilota credibile non deve iniziare da tutti i contratti o da tutta la posta aziendale. Deve scegliere una famiglia di richieste numerosa, ripetibile e reversibile. Esempi possibili sono la prima classificazione delle richieste privacy, la raccolta dei dati per una revisione contrattuale o il recupero di clausole già approvate. Non sceglierei come primo caso un contenzioso urgente o una comunicazione destinata a un’autorità.

Settimana 1: definire confini e campione

Raccogliete da 30 a 50 richieste storiche già chiuse e rimuovete i dati non necessari. Per ciascuna, annotate categoria corretta, priorità, documenti usati e decisione finale. Questo piccolo set non serve ad addestrare un modello: serve a sapere che cosa significa «corretto» per l’organizzazione.

Definite inoltre ciò che il sistema non può fare: inviare email, modificare contratti, dare un parere definitivo, accedere a cartelle non previste o creare nuove scadenze senza conferma. I divieti devono essere applicati dai permessi dell’applicazione, non affidati a una frase nel prompt.

Settimana 2: costruire intake e classificazione

Create uno schema dei campi obbligatori e una tassonomia iniziale di cinque-dieci classi. Fate produrre al modello un oggetto strutturato con classe, urgenza proposta, informazioni mancanti e motivazione breve. Confrontate il risultato con le etichette assegnate dal team.

In questa fase nessun output raggiunge un utente finale. Gli errori vanno separati: categoria sbagliata, urgenza sottostimata, dato inventato, documento ignorato, accesso non consentito. Un unico punteggio medio nasconde il tipo di rischio.

Settimana 3: aggiungere le fonti

Collegate un archivio ristretto di precedenti approvati. Ogni risultato deve mostrare titolo, versione, proprietario e data di validità. Un documento scaduto può essere utile come contesto storico, ma non deve apparire come procedura corrente.

Misurate anche il fallimento corretto: quando la base documentale non contiene una risposta, il sistema deve dirlo e chiedere l’intervento umano. In un processo legale, l’astensione motivata vale più di una risposta plausibile.

Settimana 4: lavorare in shadow mode

Il team continua a gestire le richieste con il processo normale, mentre il sistema produce in parallelo classificazione e scheda preparatoria. Solo alla fine si confrontano tempi, omissioni e correzioni. È un modo concreto per evitare che la novità alteri il campione di prova.

Se il pilota supera le soglie, si può aprire un uso assistito con approvazione obbligatoria. Se non le supera, si restringono le classi o le fonti. Estendere il perimetro per compensare una qualità debole aumenta soltanto il numero di errori possibili.

Le metriche che impediscono l’effetto demo

AT&T dichiara che il successo non sarà misurato dalla quantità di tecnologia distribuita, ma dal miglioramento della qualità, dall’accessibilità della conoscenza, dalla creazione di capacità riutilizzabili e dal tempo restituito al lavoro che richiede esperienza e giudizio. È un criterio più utile del conteggio degli utenti che hanno aperto il chatbot.

Per una PMI userei una scheda con cinque misure:

  • Accuratezza dell’instradamento: percentuale di richieste assegnate alla classe e al responsabile corretti.
  • Completezza dell’intake: percentuale di pratiche che arrivano al revisore con tutti i campi obbligatori.
  • Precisione delle fonti: quota di riferimenti realmente pertinenti e autorizzati tra quelli proposti.
  • Tasso di correzione: quante schede richiedono modifiche sostanziali prima dell’uso.
  • Tempo fino alla prima valutazione: intervallo fra invio della richiesta e disponibilità di un fascicolo verificabile per il professionista.

Aggiungerei un registro degli incidenti: accesso a un documento errato, informazione inventata, urgenza sottostimata, output inviato senza approvazione. Questi eventi non vanno diluiti nella media. Una sola esposizione di dati riservati può contare più di cento classificazioni corrette.

Per evitare una valutazione autoreferenziale, il campione deve includere casi normali, casi incompleti e casi che il sistema deve rifiutare. Un modello provato solo sulle richieste ben formate supera un esame che in produzione non esiste.

Governance: cosa resta umano

La documentazione pubblica di AT&T descrive una supervisione centralizzata del rischio AI, processi obbligatori e responsabilità lungo il ciclo di vita. Nel caso LegalEdge, l’azienda ribadisce supervisione umana, riservatezza, accountability e giudizio legale. Sono principi, non dettagli tecnici dell’implementazione; non sappiamo dai materiali pubblici quali modelli, soglie o controlli siano già operativi nel sistema futuro descritto.

Questa cautela evita di trasformare un annuncio in un risultato. I quasi 100 casi riguardano l’attività di LegalEdge nei primi sei mesi, non l’efficacia del nuovo intake in linguaggio naturale, che viene presentato come iniziativa pianificata. Il dato prova che esiste un programma operativo; non prova che la nuova architettura abbia già raggiunto determinate prestazioni.

Nel progetto di una PMI, la matrice delle responsabilità dovrebbe indicare chi possiede le fonti, chi approva la tassonomia, chi può cambiare prompt e modelli, chi rivede gli incidenti e chi firma l’output finale. Serve anche una politica di conservazione: input, allegati e log non devono restare disponibili indefinitamente solo perché potrebbero essere utili.

Il principio tecnico è semplice: l’AI propone, l’applicazione limita, la persona decide. Se il controllo esiste soltanto nella schermata finale ma il sistema ha già inviato dati, modificato record o notificato terzi, la supervisione è arrivata troppo tardi.

La lezione operativa per una PMI

Il caso AT&T non suggerisce di comprare subito un agente legale. Suggerisce di trattare la conoscenza interna come infrastruttura: ingresso unico, campi coerenti, precedenti con proprietario e validità, recupero vincolato dai permessi, revisione esplicita e metriche definite prima del rilascio.

La mia raccomandazione è iniziare da un solo passaggio preparatorio che oggi consuma tempo e genera errori visibili. L’intake è spesso il candidato migliore perché può migliorare il fascicolo senza sostituire il giudizio. Dopo quattro settimane, decidete con i dati se estendere il flusso. Se non riuscite a misurare classificazione, fonti e correzioni, non siete pronti ad automatizzare la risposta.

La differenza tra una demo e un sistema aziendale non sta nella fluidità della conversazione. Sta nella capacità di sapere chi ha chiesto cosa, quali documenti sono stati usati, quale regola ha instradato la pratica e quale persona ha approvato il risultato.

Fonti