Prodotto

Governabile prima che potente

In uno studio, l'accesso all'informazione non è mai uniforme. È il primo ostacolo all'adozione seria dell'IA, e il più raramente nominato.

In ogni organizzazione giuridica seria, l'accesso all'informazione obbedisce a una struttura rigorosa. Una pratica sensibile è aperta solo alla squadra che la tratta. Una nota interna resta interna. Certi clienti non possono essere evocati davanti a certe squadre, per conflitto d'interessi. Certi documenti sono protetti dal segreto professionale, altri da impegni contrattuali di riservatezza. Questa struttura di permessi non è un dettaglio amministrativo che si potrebbe regolare a posteriori; è una dimensione costitutiva del mestiere, alla stregua della competenza giuridica stessa.

Gli strumenti d'IA di largo consumo, e persino la maggior parte degli strumenti dedicati, ignorano quasi interamente questa struttura. Operano su un accesso indifferenziato: se il documento è nel sistema, è nel sistema. Il modello non distingue una pratica posta sotto muraglia cinese da una pratica ordinaria; non sa che un collaboratore non ha alcuna ragione legittima di vedere i documenti di una squadra vicina. Lo strato d'IA è posato sull'organizzazione come una tovaglia uniforme, e così facendo, schiaccia le regole d'accesso che la strutturano come se non esistessero.

Bisogna nominare questo ostacolo, perché è il più raramente formulato e tuttavia il più decisivo. Si parla di continuo della potenza dei modelli, della qualità delle loro risposte, della loro velocità. Non si parla quasi mai della loro governabilità, cioè della capacità di un'organizzazione di controllare, attraverso di essi, chi accede a cosa. Ora, è esattamente lì che si gioca l'adozione in uno studio: non su ciò che lo strumento sa fare, ma su ciò che permette di garantire.

La domanda non è sapere se l'IA è potente. La domanda è sapere se è governabile.

Il vero freno all'adozione non è l'utente

Si spiega volentieri la lentezza dell'adozione dell'IA con la resistenza presunta degli utenti, la loro prudenza, il loro attaccamento alle abitudini. Sul campo, è raramente la realtà. Gli utenti vogliono questi strumenti; li reclamano persino, spesso con impazienza. Chi blocca non sono gli utenti, sono i responsabili: soci, direzioni giuridiche, responsabili KM, direzioni informatiche. E non bloccano per conservatorismo, ma perché non possono, in coscienza, validare un deployment che rende la loro struttura di permessi invisibile allo strato che produce.

Il loro rifiuto non esprime alcuna diffidenza verso le proprie squadre. Esprime un'impossibilità di principio: impegnare la responsabilità di uno studio su un sistema incapace di dire, in ogni istante, chi ha accesso a cosa attraverso di esso, è semplicemente insostenibile. Il blocco non è dunque culturale, è architetturale. E un blocco architetturale non si toglie a colpi di gestione del cambiamento o di sessioni di formazione; si toglie cambiando l'architettura. Ecco perché tanti programmi di adozione falliscono dopo aver puntato tutto sulla formazione: trattano un problema di architettura come un problema di cultura.

L'adozione non urta contro la volontà degli utenti. Urta contro l'impossibilità, per i responsabili, di validare l'ingovernabile.

Un esempio concreto rende la cosa tangibile, perché si rigioca identico in molti studi. Un progetto di deployment di un assistente d'IA su larga scala viene lanciato. È sostenuto dalla direzione, finanziato, atteso dalle squadre che l'hanno provato e amato. Tutto è pronto. E il progetto si arresta di colpo al comitato di sicurezza, su una sola domanda, posta con calma dal responsabile della compliance: puoi garantirmi che un collaboratore assegnato alla pratica A non potrà mai, interrogando l'assistente, far riemergere un documento della pratica B, posta sotto muraglia cinese?

Se la risposta è no, o persino un sì esitante, il deployment non si farà, quale che sia l'eleganza dello strumento o l'entusiasmo delle squadre. E questo rifiuto è perfettamente razionale. Un solo attraversamento di muraglia basta a impegnare la responsabilità dello studio, a compromettere un mandato, a volte a farlo escludere da un'intera operazione. Di fronte a questo rischio, la potenza dello strumento non pesa nulla. Non si scambia una garanzia deontologica con un guadagno di produttività, per quanto reale sia. Il responsabile che blocca non si sbaglia: fa il suo lavoro.

Un solo attraversamento di muraglia costa più di quanto uno strumento farà mai guadagnare.

Ciò che la potenza non può riscattare

C'è, nel rifiuto dei responsabili, una logica che i progettisti di strumenti colgono male, perché ragionano in capacità mentre il responsabile ragiona in rischi. Per un progettista, uno strumento più potente è uno strumento migliore; per un responsabile, uno strumento più potente ma ingovernabile è un rischio più grande, perché fa più cose senza che si possa garantire che non farà l'unica cosa vietata. La potenza e la governabilità non sono sulla stessa scala: l'una misura ciò che lo strumento può fare, l'altra ciò che gli si può impedire di fare.

Questa asimmetria spiega perché nessun guadagno di prestazione riscatti un difetto di governabilità. Uno strumento che facesse guadagnare due ore al giorno ma non potesse garantire la tenuta stagna di una muraglia cinese non sarà adottato, perché le due ore guadagnate non compensano in nulla il rischio di un attraversamento. Non è un calcolo di redditività ordinario, in cui si soppeserebbe il pro e il contro; è una soglia, al di sotto della quale nulla è negoziabile. Sotto quella soglia, la potenza dello strumento semplicemente non pesa sulla bilancia, perché è dal lato sbagliato di una linea che il responsabile non può attraversare.

Si capisce allora perché la corsa alla prestazione, che occupa tutto il mercato, manchi ciò che decide realmente dell'adozione in studio. Ottimizzare la potenza significa migliorare ciò che non era già il punto di blocco. Il punto di blocco è altrove, in una casella che le dimostrazioni non affrontano mai perché non ha nulla di spettacolare: la capacità di garantire, a freddo, chi vede cosa. È questa casella, e non la brillantezza delle risposte, a decidere se uno strumento supera o meno il comitato di sicurezza.

Perché compartimentare a monte non basta

Si obietta a volte che basterebbe compartimentare i dati a monte, dare allo strumento accesso solo a ciò che ciascuno può vedere. L'idea sembra semplice e rassicurante, ma è ingestibile alla scala di uno studio vivo. Perché uno studio non è una struttura rigida in cui ciascuno avrebbe, una volta per tutte, un perimetro d'accesso stabile. Le squadre si ricompongono a ogni pratica, le muraglie si montano e si smontano al ritmo dei mandati, una stessa persona ha diritti diversi a seconda dell'affare, a volte a seconda della settimana.

Questa mobilità permanente è la regola, non l'eccezione. Un socio può essere escluso da una pratica lunedì per conflitto, poi esservi ammesso giovedì perché il conflitto si è sciolto. Un collaboratore può lavorare la mattina su un'operazione e vedersi, il pomeriggio, negato l'accesso a un affare concorrente. I permessi non sono uno stato che si configura una volta; sono un flusso, che segue i movimenti dello studio in tempo reale. Una compartimentazione statica, configurata a monte, è superata il giorno stesso in cui la si è posata.

Ecco perché l'unica risposta sostenibile non è congelare degli accessi, ma portare le regole dinamicamente, a ogni richiesta. Bisogna che lo strato sappia, nel momento preciso in cui un utente lo interroga, ciò che quell'utente ha il diritto di vedere quel giorno, su quella pratica, dato lo stato corrente delle muraglie. Questa valutazione non può essere delegata a una configurazione preliminare, perché la configurazione non segue il ritmo dello studio. Deve essere fatta al volo, a ogni interazione, da uno strato che conosce lo stato dei permessi nell'istante in cui risponde.

I permessi non sono uno stato che si configura. Sono un flusso da seguire a ogni richiesta.

I permessi vivono nello strato, non nel prompt

La lezione è che non si gestiscono i permessi, la riservatezza, i regimi d'accesso e le compartimentazioni interne in un prompt. Un prompt è un evento puntuale; i permessi sono una struttura permanente. Li si gestisce nell'architettura, in uno strato concepito per portarli e applicarli a ogni interazione, senza eccezione e senza dipendere dalla vigilanza dell'utente. È per questo che MAX è stato pensato, fin dall'origine, come uno strato al di sopra dei modelli e non come un assistente al loro livello: uno strato che conosce le regole d'accesso dell'organizzazione e le fa rispettare per costruzione.

Bisogna misurare cosa significhi qui « per costruzione », perché è il cuore della questione. Uno strato che applica i permessi per costruzione non può infrangerli, anche se l'utente formula una richiesta che, senza di esso, vi condurrebbe. Il rispetto delle muraglie non dipende né dalla prudenza di chi interroga, né da una configurazione che si sarebbe potuto dimenticare di aggiornare; è iscritto nel funzionamento stesso dello strato, che valuta i diritti prima di rispondere e non fa mai riemergere ciò che l'utente non ha il diritto di vedere. È questa garanzia strutturale, e non una promessa di buona condotta, che i responsabili reclamano prima di autorizzare un deployment.

L'IA giuridica realmente adottabile non è dunque la più rapida né la più impressionante in dimostrazione. È quella di cui un'organizzazione può dire, in ogni istante e senza esitare, chi ha accesso a cosa attraverso di essa. La governabilità non è un vincolo che si aggiunge alla potenza a posteriori; è la condizione perché la potenza sia, un giorno, autorizzata a servire. Uno strumento ingovernabile, per quanto potente, resta alla porta dello studio; uno strumento governabile, anche meno spettacolare, vi entra e vi resta.

Uno strato che non porta le regole d'accesso non è un'infrastruttura. È una demo che resterà alla porta.