Prodotto

Rispondere non è eseguire

Il mercato propone strumenti che rispondono. Le organizzazioni, maturando, chiedono strumenti che eseguono. Tra i due c'è un divario che la prestazione del modello non colma.

Buona parte della frustrazione che le organizzazioni giuridiche esprimono di fronte all'IA nasce da un malinteso sulla natura dell'aiuto che si aspettano. Il mercato propone massicciamente strumenti che rispondono; le organizzazioni, man mano che maturano nel loro uso, chiedono sempre più strumenti che eseguono. La frustrazione non nasce da risposte di cattiva qualità, che sono spesso eccellenti, ma da uno scarto tra ciò che viene consegnato, una risposta, e ciò che ci si aspetta, un lavoro condotto fino in fondo.

Rispondere significa trattare una richiesta puntuale e restituirla. Eseguire significa prendere in carico una funzione in un processo e condurla fino al termine. Questo articolo non verte su ciò che distingue, in teoria, questi due regimi; verte su ciò che significa, molto concretamente, eseguire, cioè su tutto ciò che accade una volta ottenuta la risposta, e che la maggior parte degli strumenti lascia interamente a carico dell'essere umano.

Ciò che comincia dopo la buona risposta

Per capire lo scarto, il modo migliore è partire dal momento in cui uno strumento che risponde ha fatto tutto il suo lavoro: ha restituito una buona risposta. L'analisi è giusta, il ragionamento è solido, la formulazione è corretta. Ed è proprio lì, nel momento in cui lo strumento considera il proprio compito assolto, che il lavoro reale comincia per il professionista. Perché una risposta, per quanto buona, non è un deliverable. È una materia prima che va ancora trasformata.

Srotoliamo ciò che resta da fare, perché è in questo srotolamento che risiede tutto il soggetto. La risposta deve essere ricollocata nel documento giusto, al posto giusto, nel formato giusto. Deve essere confrontata con le posizioni anteriori dello studio, per verificare che non le contraddica. Deve essere adattata al cliente preciso, alla sua storia, alle sue preferenze. Deve passare per una revisione, integrare i ritorni, essere validata da un senior. Deve essere archiviata, tracciata, collegata alla pratica di cui ormai fa parte. E ciascuna di queste tappe può, a sua volta, innescare una nuova domanda, quindi una nuova risposta, quindi un nuovo ciclo di trasformazione.

Questo lavoro del dopo-risposta non è né accessorio né secondario: è l'essenziale dello sforzo reale. La risposta in sé, il momento in cui il modello produce la sua analisi, rappresenta una frazione del tempo totale; tutto il resto sta nel trasformare quell'analisi in qualcosa di utilizzabile, di validato, di integrato. Uno strumento che si ferma alla risposta ha dunque fatto la parte più visibile e più piccola del lavoro, e ha lasciato la parte più pesante, e la meno visibile in dimostrazione, all'essere umano.

La risposta è il cinque per cento del lavoro. Il novantacinque per cento che segue è ciò che l'esecuzione prende in carico.

Il lavoro invisibile che porta l'utente

Finché lo strumento si ferma alla risposta, questo lavoro del dopo-risposta non sparisce: è semplicemente riversato sull'utente, che diventa l'esecutore che lo strumento non è. È lui a copiare la risposta nel documento, a verificare la coerenza con le pratiche vicine, a ricordare che una posizione contraria era stata presa sei mesi prima, a pensare di farla validare, a non dimenticare di archiviare. Ciascuno di questi gesti gli incombe perché lo strumento li ignora, e il loro accumulo finisce per pesare più del guadagno apportato dalla risposta stessa.

Questo riversamento ha un costo che non si vede da nessuna parte, ed è ciò che lo rende così facile da ignorare al momento dell'acquisto. In dimostrazione si vede solo la risposta, brillante, immediata; non si vede l'ora che l'utente passerà poi a trasformarla in deliverable, perché quell'ora si svolge dopo la dimostrazione, nel lavoro reale. Lo strumento sembra dunque fare l'essenziale mentre fa il più facile, e il costo di tutto ciò che non fa resta invisibile fino al deployment, dove riappare sotto forma di delusione: l'IA fa risparmiare meno tempo di quanto si sperasse, perché prende in carico solo la punta emersa del lavoro.

Bisogna vedere bene che questo lavoro riversato non è lavoro giuridico in senso nobile: non è ragionamento, non è giudizio, è manipolazione. Ricollocare una risposta al posto giusto, verificare una coerenza, pensare di archiviare sono gesti necessari ma senza valore aggiunto intellettuale, esattamente il genere di compiti che un'infrastruttura dovrebbe assorbire per restituire il professionista al suo mestiere. Lasciare questi gesti all'essere umano significa fargli pagare in attenzione ciò che un'esecuzione ben concepita gli risparmierebbe.

Eseguire, gesto dopo gesto

Che cosa significa allora, concretamente, prendere in carico quel novantacinque per cento? Non significa produrre una risposta migliore, né produrne diverse; significa condurre il lavoro attraverso le sue tappe successive. Uno strumento che esegue non restituisce una risposta per poi attendere la domanda successiva: avanza. Sa qual è la tappa in corso e quale la successiva, prepara ciò che può esserlo, applica le regole che valgono tra le tappe, innesca i contributi umani al momento giusto, conserva la traccia di ciò che è stato fatto. Là dove lo strumento che risponde restituisce la mano dopo ogni scambio, lo strumento che esegue tiene il filo e lo prosegue.

Bisogna sciogliere qui un malinteso, perché ritorna sempre: eseguire non significa fare a meno dell'essere umano. L'esecuzione di cui si parla non è mai autonoma, è governata. Tra le tappe che prende in carico, riserva punti precisi in cui è richiesta, chiesta, tracciata una decisione umana. Eseguire non è dunque sostituire il giudizio con l'automatismo; è avanzare tra i momenti in cui il giudizio è necessario, preparando ciascuno di quei momenti perché l'essere umano vi arrivi con tutto ciò che gli serve, e solo ciò che gli serve.

Eseguire non è fare a meno dell'essere umano. È avanzare tra i punti in cui l'essere umano decide.

Questo modo di collocare l'essere umano cambia la qualità del suo intervento. Quando non c'è esecuzione, l'essere umano è sollecitato da ogni parte, in continuazione, per decisioni grandi e piccole mescolate, e la sua attenzione si disperde sulla meccanica quanto sul merito. Quando l'esecuzione porta la concatenazione, l'essere umano è sollecitato solo nei punti che richiedono davvero il suo giudizio, e vi arriva con un contesto preparato anziché con una pagina bianca. Decide meglio perché decide meno spesso e su cose che ne valgono la pena. L'esecuzione non svaluta il giudizio umano; lo concentra là dove ha più valore.

Si può dare a questa idea la precisione di un esempio. Preparare un parere su un'operazione presuppone di inquadrare la richiesta, riunire le fonti, verificarne l'attualità, confrontare le posizioni, redigere, far revisionare, integrare i ritorni, far validare, archiviare. Uno strumento che risponde può produrre una buona analisi in una qualsiasi di queste tappe, a condizione che gliela si chieda. Uno strumento che esegue fa passare il lavoro da una tappa alla successiva: sa che la redazione viene dopo il confronto delle posizioni, che la validazione viene dopo la revisione, e prepara ogni transizione invece di lasciarla a carico dell'utente. Il professionista non deve più rifare il direttore d'orchestra a ogni battuta; interviene là dove il suo giudizio conta, il resto essendo già tenuto.

Perché l'esecuzione costa così tanto da costruire

Questa differenza si traduce in scelte ingegneristiche molto concrete, e costose. Uno strumento che risponde può accontentarsi di un'interfaccia in cui si pongono domande. Uno strumento che esegue deve seguire stati, sapere a che punto è ogni lavoro; gestire permessi, sapere chi può fare cosa a quale tappa; innescare tappe, concatenare senza intervento quando l'intervento non è richiesto; integrare contributi umani, situarli, tracciarli; produrre artefatti che persistono. I due strumenti si appoggiano forse sugli stessi modelli, ma ciò che costruiscono al di sopra non ha né la stessa ambizione né lo stesso costo.

È proprio questo costo a spiegare perché così pochi editori abbiano imboccato questa strada. Costruire un assistente che risponde è rapido e dimostrabile; costruire uno strato che esegue presuppone un'infrastruttura di orchestrazione e di governance che un assistente non ha mai bisogno di portare. L'investimento è di tutt'altra misura, e non si vede in dimostrazione, dove un assistente brillante crea l'illusione. Ma è questo investimento, e lui solo, a separare uno strumento di uso individuale da un'infrastruttura capace di portare il lavoro di un'organizzazione.

Il mercato scoprirà che l'IA che risponde bene ha un soffitto. La prossima onda verrà dall'IA che esegue.

È questa ambizione di esecuzione, e non la ricerca della risposta perfetta, a strutturare la Legal Semantic Layer di MAX. Perché il lavoro giuridico reale non consiste nell'ottenere buone risposte, ma nel condurre pratiche fino a deliverable, attraverso decine di tappe di cui la risposta non è che la prima. Una risposta in più non cambia la natura di un mestiere; un'esecuzione governata, condotta da un capo all'altro, sì.

È in questa direzione che si costruisce il lavoro giuridico realmente assistito dall'IA, e in nessun'altra.