Architettura

Il test che separa la demo dall'infrastruttura

C'è un test semplice per sapere se uno strumento d'IA è un'infrastruttura o una demo. Non sta nella demo. Sta in ciò che accade quando se ne esce.

Esiste un test semplice, e sorprendentemente affidabile, per valutare se uno strumento d'IA sia un'infrastruttura o una demo. Il test non sta nella qualità della dimostrazione, che non prova quasi nulla, perché una dimostrazione è per natura una cornice scelta, concepita per valorizzare lo strumento, con le domande giuste, il corpus giusto, gli esempi giusti. Ogni strumento, anche fragile, impressiona nella cornice che si è disegnato da sé. È una scena, e su una scena tutto è regolato perché nulla cada. Il test comincia là dove la dimostrazione si ferma: in ciò che accade quando si esce dalla cornice scelta, cioè nelle condizioni in cui il lavoro reale ha luogo.

Bisogna misurare che cosa sia, davvero, una dimostrazione. Non è un inganno; è una selezione. Vi si mostra lo strumento nelle condizioni in cui riesce, sui casi che tratta bene, con un corpus di cui si conosce la forma. Nulla di tutto ciò è disonesto, ma nulla di tutto ciò somiglia alla realtà di un deployment, dove i casi arrivano in disordine, dove il corpus è vasto ed eterogeneo, dove gli utenti hanno fretta e le domande sono mal poste. Giudicare uno strumento sulla sua dimostrazione è come giudicare un attore su una battuta imparata: non si impara nulla della sua capacità di improvvisare quando il copione gli sfugge.

Il test si può formulare in una frase. Non chiedete a uno strumento cosa sa fare; chiedetegli cosa accade quando il suo modello migliore viene tolto, quando la sessione precedente è dimenticata, quando la pratica riprende tre settimane dopo, quando un altro professionista continua il lavoro, quando i permessi cambiano in corso d'opera. Le risposte a queste domande, e non la brillantezza della demo, dicono di quale natura sia lo strumento. Perché sono queste situazioni, e non le domande ben poste di una presentazione, a comporre la giornata ordinaria di un'organizzazione.

Una demo impressiona nella cornice scelta. Un'infrastruttura regge fuori da quella cornice.

Si può persino rovesciare il test per renderlo ancora più tagliente. Anziché mettere alla prova lo strumento sui suoi punti di forza, mettetelo alla prova sui suoi punti di rottura. Che ne è del contesto quando la conversazione si chiude? Dove va la memoria quando cambia il fornitore del modello? Chi ricorda la decisione presa il mese scorso quando è un collega a riaprire la pratica? Una demo risponde a queste domande con un silenzio imbarazzato, o con un « bisognerebbe riconfigurare ». Un'infrastruttura vi risponde con il suo funzionamento normale, perché è stata concepita per queste situazioni, e non contro di esse. La differenza non è che l'una gestisca meglio questi casi: è che l'una li ha previsti come il cuore del problema, e l'altra come eccezioni.

Questa opposizione tra il cuore e l'eccezione è più profonda di quanto sembri. Uno strumento pensato come demo tratta la continuità, la memoria, la condivisione come casi particolari da gestire a posteriori, una volta assicurata la funzione principale. Uno strumento pensato come infrastruttura li colloca al centro fin dalla progettazione, perché sa che è lì che si gioca il valore reale. Il primo aggiunge la continuità come un'opzione; il secondo è costruito attorno a essa. E questa differenza nell'ordine delle priorità, invisibile in una dimostrazione, determina l'intero comportamento dello strumento una volta messo in deployment.

Questa distinzione non è una sfumatura di prodotto, è una frontiera di categoria. E la maggioranza degli strumenti d'IA giuridica di oggi si trova, malgrado la qualità reale delle loro risposte, dal lato della demo. Non per mancanza di serietà, ma per mancanza di progettazione: sono stati pensati per rispondere bene, non per tenere l'operativo. Ora, tenere l'operativo non è una versione migliorata del rispondere bene. È un'altra cosa, e quest'altra cosa non si ottiene perfezionando la risposta, ma costruendo ciò che la circonda e la fa durare.

Perché tenere l'operativo significa tenere più cose insieme. Tenere un contesto che non sparisce tra due sessioni. Tenere una memoria che non dipende dal modello interrogato. Tenere permessi che restano validi quando le persone cambiano. Tenere una coerenza tra decisioni prese a settimane di distanza. Tenere una tracciabilità che sopravvive ai cambi di strumento. Ciascuna di queste esigenze, presa isolatamente, è alla portata di un buon prodotto. È la loro congiunzione, nel tempo, a creare la difficoltà, ed è questa congiunzione che nessuna demo mette mai alla prova.

Una funzionalità funziona nella cornice prevista dal progettista. Un'infrastruttura regge anche quando se ne esce.

Questa esigenza di tenere più cose insieme non è una difficoltà tecnica in più, da riporre tra le altre. È la difficoltà propria dell'operativo, quella che lo definisce. Un assistente non deve mai incontrarla, perché vive nell'istante: risponde, poi l'istante si richiude, e nulla gli sopravvive che vada articolato con altro. Un'infrastruttura, invece, conosce solo istanti collegati: ogni risposta si iscrive in una sequenza, ogni decisione in una storia, ogni accesso in una cornice di permessi. È questa messa in relazione permanente, e non la risposta in sé, a costituire il suo lavoro reale e a renderla costosa da costruire.

Bisogna insistere su questa parola, simultaneamente, perché è essa a creare tutta la difficoltà, ed è essa che le dimostrazioni fanno sparire. Tenere il contesto, o la memoria, o i permessi, presi uno a uno, è un problema risolvibile, e molti strumenti ne risolvono uno brillantemente. Tenerli tutti insieme, nello stesso momento, per l'intera durata di una pratica reale, è un problema di un'altra scala, perché ogni esigenza interagisce con le altre e nessuna può essere trattata per conto suo. La memoria dipende dai permessi, i permessi dipendono dal contesto, il contesto dipende dalla traccia: non se ne può isolare una senza rompere le altre. È esattamente questa simultaneità che una demo mostra di rado, e che un deployment rivela sempre.

Si può dare a questa idea una forma quasi sperimentale. Prendete uno strumento che riesce in ciascuna di queste prove separatamente, in dimostrazione: tiene il contesto quando glielo si chiede, ritrova una decisione quando lo si interroga, rispetta un permesso quando lo si mette alla prova. Mettetelo ora in situazione reale, dove i tre vanno tenuti nello stesso momento, su una pratica che dura, tra più mani. È lì, e solo lì, che si vede se le capacità erano funzioni giustapposte o le facce di uno stesso sistema. Un assemblaggio di buone funzioni si disgrega sotto la simultaneità; un'infrastruttura l'attraversa senza pensarci, perché è stata concepita tutta d'un pezzo.

Gli strumenti che presentano l'una o l'altra di queste capacità isolatamente non tengono l'operativo: tengono una funzionalità. E la differenza, invisibile in fase pilota, diventa lampante all'uso. In pilota, il corpus è piccolo, gli utenti sono attenti, i casi sono scelti, e la funzionalità basta a creare l'illusione. Al deployment, il corpus si gonfia, gli utenti hanno fretta, i casi sono qualsiasi, e lo strumento che teneva solo una funzionalità cede su tutto il resto. Ciò che brillava nella demo diventa il punto preciso in cui il sistema molla, e la promessa che aveva conquistato la decisione si rovescia in delusione.

Tenere una di queste cose è una funzionalità. Tenerle tutte insieme, nel tempo, è un'infrastruttura.

C'è, in questa linea di demarcazione, qualcosa di rassicurante per chi deve scegliere. Non richiede competenza tecnica per essere applicata; chiede soltanto di porre le domande giuste e di ascoltare la natura delle risposte. Non serve capire come sia costruito un sistema per chiedergli che ne è di una pratica lasciata tre settimane, ripresa da qualcun altro, sotto un modello diverso. La risposta, o l'imbarazzo che suscita, dice più di qualsiasi scheda tecnica. Il test è alla portata dell'acquirente, proprio perché verte su situazioni che egli conosce meglio di chiunque: le proprie.

Questa constatazione ha una conseguenza pratica per chi deve scegliere uno strumento, e inverte il modo abituale di valutare. La buona valutazione non consiste nell'organizzare una bella dimostrazione e nel giudicare la qualità delle risposte, perché è esattamente ciò in cui ogni strumento riesce. Consiste nel fabbricare, deliberatamente, le condizioni del deployment reale: un corpus ampio e disordinato, riprese a distanza, passaggi di consegne tra più persone, cambi di contesto in corso d'opera. Uno strumento che regge in queste condizioni scomode è un'infrastruttura; uno strumento che regge solo nella cornice curata della dimostrazione è una demo, quale che sia la qualità di ciò che mostra.

Il mercato si selezionerà su questo test, e la selezione è già cominciata. Gli strumenti che restano nel regime della demo continueranno a sedurre in pilota e a deludere al deployment, e si attribuirà il loro fallimento all'adozione, o alla maturità dell'IA, mentre dipende dalla loro progettazione. Le architetture pensate fin dall'origine per tenere l'operativo, invece, supereranno l'asticella del deployment perché sono state costruite per ciò che accade quando si esce dalla cornice. E questa selezione, una volta avviata, non si invertirà, perché non si trasforma una demo in infrastruttura con un aggiornamento: bisognerebbe ricostruirla.

È su questo test, e non sulla qualità di una dimostrazione, che MAX è stato concepito per essere valutato. La Legal Semantic Layer non cerca di rispondere meglio in una cornice scelta; cerca di tenere, simultaneamente e nel tempo, il contesto, la memoria, i permessi e la coerenza di una pratica reale. Perché l'unica domanda che separa un prodotto da un'infrastruttura non è ciò che mostra nella sua demo. È ciò che resta quando la demo è finita.