Prodotto

Nessuno vuole una scheda in più

Il primo ostacolo all'adozione dell'IA giuridica non è la qualità dei modelli. È il gesto, ripetuto mille volte, di trasferire l'informazione da uno strumento a un altro.

Osservate un professionista del diritto per un'intera giornata, in un qualsiasi studio, e vedrete la stessa scena. Una casella di posta aperta in permanenza. Un sistema di gestione documentale. Uno strumento di gestione delle pratiche. Un editor di testo. Un comparatore di documenti. Una piattaforma di videoconferenza, un'altra di firma. E ormai, di lato, in una scheda a parte, un copilot. Alla fine della giornata, questa persona ha trascorso una parte significativa del proprio tempo non a esercitare il diritto, ma a trasferire informazione da un ambiente all'altro, a mano, copiando, incollando, riformulando, rimpatriando.

Questa scena è così banale che non la si vede più. Si è installata per strati, uno strumento dopo l'altro, ciascuno a risolvere un problema reale, e la somma ha finito per creare un problema che nessuno aveva scelto: la frammentazione del lavoro tra una decina di ambienti che non si parlano. Il professionista è diventato, senza averlo voluto, l'unico legame tra strumenti che si ignorano. È lui a portare il contesto da un luogo all'altro, perché nessun sistema lo fa al suo posto.

Questa frizione è diventata così ordinaria che non la si formula nemmeno più. È tuttavia il primo ostacolo reale all'adozione seria dell'IA giuridica, ben prima della qualità dei modelli o della pertinenza delle risposte. Si dibatte sulla performance dei sistemi mentre il punto di blocco è altrove, a monte, nel semplice fatto di doversi spostare per sollecitarli.

Il primo freno all'IA giuridica non è ciò che sa fare. È il luogo dove bisogna andare per chiederglielo.

La scheda che si impila invece di sostituire

Quando uno strumento arriva con la propria interfaccia, il proprio quadro, il proprio vocabolario, aggiunge un carico senza toglierne alcuno. Non sostituisce nulla; si impila. L'utente deve lasciare il contesto del proprio lavoro, entrare in quello dello strumento, tradurre il proprio bisogno nella lingua dello strumento, attendere, valutare la risposta, poi rimpatriarla a mano nel proprio flusso reale. Ciascuna di queste tappe è minuscola; la loro ripetizione, invece, non lo è.

Occorre misurare bene la natura di questo costo, perché spiega perché è così spesso trascurato. Non è un costo puntuale e visibile, del genere che si valuta prima di acquistare. È un costo diffuso, fatto di qualche secondo perso a ogni sollecitazione, moltiplicato per il numero di sollecitazioni in una giornata, poi per il numero di giorni, poi per il numero di utenti. Preso isolatamente, ogni trasferimento è trascurabile; è precisamente per questo che non lo si conta. Ma ciò che non si conta finisce per decidere.

La cosa più perniciosa è che questo costo non si vede da nessuna parte. Non figura su alcuna fattura, non si iscrive in alcun indicatore, non si confronta con nulla. Si dissolve nel quotidiano, sotto forma di qualche secondo perso mille volte al giorno, ed è precisamente perché è invisibile che finisce per decidere il fallimento o il successo di un deployment. Uno strumento il cui ogni uso costa un piccolo sforzo di spostamento sarà, alla scala, disertato, qualunque sia la brillantezza di ciò che produce una volta che vi si è entrati.

Un piccolo sforzo, mille volte al giorno, su centinaia di persone, non resta piccolo. Decide tutto.

Si vede allora che il trasferimento manuale da un ambiente all'altro non ha nulla di un compito accessorio senza importanza. Occupa un tempo reale, frammenta l'attenzione, interrompe il filo del lavoro nel momento preciso in cui occorrerebbe sostenerlo. E soprattutto, non apporta nulla: ricopiare un'informazione da uno strumento a un altro non crea alcun valore giuridico, è una pura perdita, una spesa di energia che il lavoro intellettuale non esige e che solo l'architettura degli strumenti impone.

Il trasferimento manuale da uno strumento all'altro non è lavoro giuridico. È costo d'uso travestito da produttività.

Venire là dove il lavoro ha già luogo

Se il costo nasce dallo spostamento, allora il solo modo di sopprimerlo non è rendere lo spostamento più gradevole, ma sopprimerlo del tutto. Uno strumento che non chiede di andare a lui non ha bisogno di essere più rapido da aprire o più semplice da imparare: non deve essere aperto, né appreso come un luogo separato, perché non è un luogo. Agisce là dove il lavoro si fa già, nella casella di posta, nell'editor, nel sistema di pratiche, senza reclamare che se ne esca.

Questo rovesciamento cambia la domanda di adozione da cima a fondo. Finché uno strumento è una destinazione, la domanda è: come convincere le persone ad andarci, e a ritornarci, giorno dopo giorno? Non appena uno strumento cessa di essere una destinazione, questa domanda scompare, perché non c'è più alcun luogo dove andare. L'utente non deve decidere di usare l'IA; essa è presente nell'ambiente che usa comunque. Non gli si chiede di aggiungere un gesto alla sua giornata, si toglie dalla sua giornata un gesto che non avrebbe mai dovuto trovarvisi.

Questo modo di procedere non attiene al comfort, ma alla viabilità alla scala. Un'infrastruttura che si incarna negli strumenti esistenti non si scontra con il soffitto di adozione che insidia ogni destinazione, perché non chiede a nessuno di cambiare le proprie abitudini. Si annida nei flussi già installati, ed è precisamente perché non esige alcun gesto nuovo che può trasformare il modo di lavorare senza farne pagare il costo d'ingresso. La trasformazione avviene da sotto, senza chiedere sforzo a coloro che trasforma.

Un'infrastruttura non chiede all'organizzazione di adattarsi a essa. Si annida in ciò che l'organizzazione fa già.

Perché la disciplina non salverà l'adozione

Di fronte a questa constatazione, la risposta spontanea consiste nel minimizzare. Si obietterà che l'utente si abitua, che una scheda in più non è un dramma, che basta un po' di disciplina per integrare il nuovo strumento nei propri gesti. Questo argomento ha l'aria ragionevole, e lo è, entro un certo perimetro: per un utente motivato, nell'arco di qualche settimana, la disciplina basta in effetti a superare la frizione.

Ma questo perimetro non è quello di un deployment reale. Ciò che è vero per un utente motivato nell'arco di qualche settimana cessa di esserlo per duecento persone nell'arco di due anni, sotto la pressione del quotidiano, nelle giornate cariche in cui ogni secondo conta e in cui il riflesso prevale sul buon proposito. La disciplina è una risorsa rara, distribuita in modo ineguale, e soprattutto fluttuante: è alta il primo mese, si erode in seguito. Fondare l'adozione di uno strumento sulla disciplina dei suoi utenti significa fondarla su ciò che cede per primo.

L'architettura, al contrario, è costante. Uno strumento che non chiede alcun gesto nuovo non dipende dalla motivazione di chi lo usa: funziona altrettanto bene il primo giorno quanto il centesimo, per l'entusiasta come per il riluttante, nella giornata calma come nella giornata sovraccarica. È questa costanza a separare uno strumento adottato durevolmente da uno strumento abbandonato dopo l'entusiasmo iniziale. La differenza non tiene alla qualità di ciò che lo strumento produce, ma a ciò che esige perché vi si acceda.

Ecco perché la questione della scheda non è una questione di ergonomia di superficie, ma una questione di categoria. Uno strumento che chiede all'organizzazione di venire a lui e uno strumento che viene là dove l'organizzazione lavora già non sono due varianti dello stesso prodotto: sono due specie diverse, con due destini diversi. L'uno ha un soffitto di adozione fissato dalla pazienza dei suoi utenti; l'altro non ne ha, perché non chiede alcuna pazienza.

Non sono due varianti dello stesso prodotto. Sono due categorie diverse, e una sola supera la scala di un'organizzazione intera.