A febbraio 2025 un tribunale federale del Minnesota ha ammesso una class action contro UnitedHealth, una delle più grandi assicurazioni sanitarie americane. L’oggetto del contendere era un algoritmo chiamato nH Predict, usato dalla società per valutare la durata delle cure riabilitative dei pazienti Medicare Advantage. Secondo le accuse, il sistema produceva decisioni di interruzione delle cure con un tasso di errore stimato attorno al 90%, evidenziato dal fatto che la maggior parte dei pazienti che facevano ricorso ottenevano una revisione favorevole. Il caso non riguardava un fallimento tecnologico isolato. Riguardava una governance dell’errore costruita male, una catena di supervisione umana ridotta al minimo, e un’azienda che aveva trattato l’AI come componente di efficienza operativa invece che come componente di un sistema di responsabilità verso il cliente finale.
Indice degli argomenti
Fiducia operativa AI: dal caso UnitedHealth al mercato
Casi del genere, che cominciano ad arrivare nei tribunali di mezzo mondo, raccontano meglio di mille analisi quale sia la vera discriminante delle prossime fasi di mercato dell’AI applicata. La discriminante non riguarda la qualità del modello sottostante, né l’eleganza dell’interfaccia, né la velocità di crescita. Riguarda la capacità di costruire fiducia operativa, e di proteggerla quando arrivano gli inevitabili errori. La fiducia, in questo contesto, va intesa come architettura più che come sentimento dell’utente. Un’architettura fatta di soglie esplicite, log, tracciabilità, governance dell’eccezione, escalation rules, e una cultura organizzativa che sa cosa fare quando il sistema sbaglia.
Per chi costruisce e per chi compra AI applicata, questa è probabilmente la conversazione più rilevante dei prossimi due anni, e per ragioni che hanno tanto a che fare con la maturità del mercato quanto con il quadro regolatorio europeo che sta entrando in piena applicazione. L’AI Act europeo, approvato nel 2024 ed entrato gradualmente in vigore, diventerà pienamente applicabile per i sistemi ad alto rischio dell’Annex III dal 2 agosto 2026, con sanzioni che possono arrivare fino al sette per cento del fatturato globale per le violazioni più gravi. Per molte aziende italiane ed europee, questa scadenza pesa come fattore di competitività concreto, prima ancora che come problema legale astratto, perché i clienti enterprise più strutturati cominciano a chiedere ai fornitori AI conformità verificabile prima di firmare i contratti.
I tre livelli della fiducia nei sistemi AI
La fiducia, in un sistema AI, lavora su tre livelli diversi che spesso vengono confusi tra loro. La fiducia immediata nasce dalla prima impressione, dalla qualità apparente degli output, dalla pulizia dell’interfaccia. È la più facile da generare e la più facile da perdere, perché si appoggia su segnali superficiali che non resistono al primo errore in un caso sensibile.
Dalla prima impressione alla delega operativa
La fiducia strutturale è quella che nasce dall’osservazione del comportamento del sistema nel tempo. Le persone che lavorano con il sistema costruiscono un modello mentale di quando il sistema funziona bene, quando è incerto, quando va supervisionato. Questa fiducia richiede mesi per formarsi, ma è molto più resistente alla singola eccezione, perché chi ha lavorato con il sistema sa già che non è infallibile, sa dove sbaglia, e ha imparato a integrare quella conoscenza nel proprio modo di usarlo.
La fiducia operativa è quella che permette all’organizzazione di delegare al sistema responsabilità sempre più importanti, fino al punto in cui le persone progettano il proprio lavoro contando sulla sua presenza. È la fiducia che produce vero vantaggio competitivo, perché trasforma il sistema in infrastruttura. Costruirla richiede non solo tempo, ma anche un’architettura di governance che la renda razionale: sistemi di log, criteri di valutazione, soglie di escalation, e ruoli chiari di responsabilità per chi risponde quando le cose vanno storte.
Le tre fiduce non si saltano, si accumulano. Senza la prima, il sistema non viene adottato. Senza la seconda, l’adozione resta superficiale. Senza la terza, il sistema non scala oltre l’uso episodico. Le startup AI che reggono meglio in questa fase sono quelle che progettano per tutte e tre fin dall’inizio, e che non confondono il successo del primo livello con la maturità degli altri due.
Governance AI come parte del prodotto
Nelle aziende dove l’AI funziona davvero, la governance è un pezzo del prodotto, non un capitolo separato del progetto. Gli aspetti operativi della governance (chi vede i log, chi può modificare il comportamento del sistema, chi approva una nuova versione, come si gestiscono gli errori, dove sta la soglia tra gestione automatica e supervisione umana) vengono progettati insieme al prodotto, non dopo. Le aziende che invece trattano la governance come adempimento da affrontare al momento del deployment si trovano spesso a dover ridisegnare il prodotto a sei mesi dal lancio, perché qualche aspetto della governance è emerso troppo tardi.
Il credito come esempio di autonomia e supervisione
Un esempio concreto chiarisce il punto. Un sistema AI che opera in un workflow di credito può essere progettato in due modi diversi. Nel primo, il sistema produce una raccomandazione di scoring, che viene visualizzata all’operatore insieme alle ragioni della raccomandazione e alle fonti utilizzate, e l’operatore decide cosa farne. Nel secondo, il sistema esegue lo scoring direttamente, in autonomia, e l’operatore interviene solo nei casi che superano una soglia di rischio o di incertezza. I due modi producono valore diverso, hanno costi operativi diversi, espongono a rischi diversi, e richiedono architetture di governance diverse. La scelta tra i due ha natura strategica prima ancora che tecnica, e va fatta con il management di linea, non con il team di sviluppo.
Le decisioni di governance progettate bene si vedono nei dettagli. Se il sistema ha un’interfaccia chiara per gestire le eccezioni, se l’operatore ha sempre visibilità sulle ragioni di una raccomandazione, se il log è facilmente consultabile per ricostruire una decisione passata, se le soglie di escalation sono esplicitate e modificabili, se il versioning del comportamento del sistema è tracciato, allora il prodotto ha una struttura di governance che lo protegge nel tempo. Se invece queste cose sono assenti, abbozzate o nascoste in pannelli di amministrazione che nessuno consulta, la prima crisi le porterà allo scoperto pagando un prezzo alto.
Tre modi di tenere l’umano nel sistema
Una distinzione utile per ragionare sulla fiducia operativa è quella tra i tre rapporti possibili tra umano e sistema. Nel primo, human in the loop, l’umano interviene su ogni passaggio operativo: approva e corregge, valida o completa quanto il sistema ha prodotto. È la modalità più stretta, e si applica quando il rischio è alto, quando i casi sono sensibili, quando la fiducia è ancora bassa. Nel secondo, human on the loop, l’umano supervisiona dall’alto: definisce soglie, controlla anomalie, interviene solo nelle eccezioni. Si applica quando il rischio è medio, i processi sono più maturi, la fiducia è cresciuta. Nel terzo, human out of the loop, lo strumento opera in autonomia entro limiti definiti, e l’umano resta come progettista delle regole più che come guardiano del singolo caso. Si applica solo quando il rischio è basso, le azioni sono reversibili, e la fiducia è consolidata.
Autonomia appropriata, non autonomia massima
Non esiste una risposta universale alla domanda “quanta autonomia concedere”. Dipende dal rischio, dal costo dell’errore, dalla reversibilità delle azioni, dalla maturità del processo. Un buon design non cerca subito l’autonomia massima, cerca l’autonomia appropriata, e la costruisce per gradi. Le aziende che spingono troppo presto verso l’autonomia, perché la promettono i pitch dei fornitori o perché sembra più moderno, si trovano spesso a dover fare marcia indietro dopo il primo incidente. Le aziende che invece costruiscono per gradi, partendo dal massimo controllo umano e rilassandolo progressivamente man mano che il sistema dimostra affidabilità, accumulano fiducia operativa con basi molto più solide.
L’AI Act europeo, nel suo impianto, riflette questa stessa logica per i sistemi ad alto rischio. Non vieta l’autonomia, richiede che sia progettata così da consentire human oversight effettiva, con la documentazione tecnica che dimostra come il sistema sia progettato per permettere a un umano di intervenire quando necessario. Per molte aziende che operano in settori regolati, conformarsi rappresenta più di un requisito legale: è anche un’occasione per mettere in ordine pratiche di governance che spesso erano improvvisate.
Errore tollerabile: la soglia che rende governabile l’AI
Una delle conversazioni più produttive che ho avuto con team che lanciano sistemi AI riguarda l’errore tollerabile. Ogni organizzazione ha un proprio budget implicito di errore, anche quando non lo dichiara. Alcuni processi possono tollerare imprecisioni modeste purché il guadagno in velocità sia alto. Altri richiedono controllo stretto anche su dettagli apparentemente minori, perché l’impatto di un singolo errore è alto. Non riconoscere queste soglie, e non comunicarle esplicitamente all’organizzazione, è una delle cause più frequenti di blocco dell’adozione.
Le tre categorie di errore da esplicitare
Il punto di svolta, in molti progetti, arriva quando qualcuno mette nero su bianco tre categorie di errori. Errori che l’operatore può correggere in poco tempo senza rilevante impatto sul processo, e che sono tollerabili. Errori che richiedono rielaborazione ma che restano dentro il perimetro del lavoro normale, e che sono accettabili se restano sotto una certa percentuale dei casi totali. Errori che toccano aspetti sensibili (importi sopra soglia, clienti specifici, scenari regolatori), e che sono inaccettabili e devono triggerare automaticamente un’escalation umana.
Quando queste tre categorie sono esplicitate e condivise, il sistema diventa gestibile, perché tutti sanno dove stanno i confini, cosa fare quando un errore avviene, chi è responsabile di rispondere. Quando non lo sono, il primo errore visibile genera reazioni sproporzionate, perché manca la cornice in cui collocarlo. Lo scarto tra le due situazioni non sta nel sistema, sta nella governance attorno al sistema.
In una società di servizi legali con cui ho lavorato, il punto di svolta è arrivato esattamente in questo modo. Il sistema AI assisteva la redazione di contratti ricorrenti. Funzionava bene, ma l’adozione si era fermata dopo tre settimane perché nessuno sapeva quale tipo di errore fosse accettabile e quale no. Quando il responsabile del team ha messo nero su bianco le tre categorie di errore, il sistema è diventato gestibile. Sei mesi dopo copriva il settanta per cento della produzione documentale dello studio, e il tempo medio di autonomia operativa per un nuovo collaboratore era sceso da quattro mesi a sei settimane. La fiducia è nata dalla chiarezza dei confini, più che dalla potenza del modello sottostante.
Osservabilità AI e verificabilità delle decisioni
Non serve una spiegazione filosoficamente completa del funzionamento del modello. Serve una spiegabilità sufficiente a governare il processo: chi ha fatto cosa, quale fonte è stata usata, quale versione del sistema ha prodotto un certo output, quali controlli sono stati superati o falliti, quale operatore è intervenuto, quale regola ha generato l’escalation. La differenza tra spiegabilità completa e sufficiente pesa nella pratica, perché la prima è spesso impossibile e la seconda è quasi sempre praticabile.
Un’organizzazione si fida più facilmente di ciò che può osservare e auditare, anche se non ne comprende ogni dettaglio matematico, rispetto a uno strumento potente ma opaco. La visibilità operativa riduce l’ansia politica e il rischio percepito, e in contesti dove la posta è alta riduce anche il rischio reale, perché permette di identificare problemi prima che si trasformino in crisi.
Quando si costruisce un prodotto AI applicato a workflow sensibili, investire in osservabilità è uno degli investimenti meno spettacolari e più strategici. Strumenti che permettono di rispondere rapidamente a domande tipo “perché il sistema ha prodotto questo output in questo caso?”, “quali fonti ha consultato?”, “in quale versione del modello è stato addestrato?”, “quale operatore è intervenuto e quando?”. Sono tutte domande che, in caso di crisi, faranno la differenza tra un incidente gestibile e un incidente che si trasforma in problema strutturale.
AI Act e fiducia operativa come vantaggio competitivo
Tutto questo, letto insieme, racconta una conclusione che attraversa l’intera rubrica. La fiducia operativa, costruita attraverso governance esplicita, soglie chiare, osservabilità, gestione dell’errore, è probabilmente il moat più resistente che una startup AI possa costruire nei prossimi anni. Più resistente del modello sottostante, perché i modelli si commoditizzano. Più resistente del codice, perché il codice si riscrive in fretta con i tool moderni. Più resistente dei dati grezzi, perché i dati si possono ricostruire o comprare.
La fiducia, invece, si costruisce stando dentro processi reali, gestendo errori reali, costruendo relazioni con compliance officer, legal, IT security, middle management che diventano sponsor interni del sistema. È un capitale relazionale e operativo che non si scarica e che non si compra, e che in caso di sostituzione il cliente dovrebbe ricostruire da zero con il nuovo fornitore. Questo è il moat più puro che esiste in questa fase di mercato.
Perché la governance diventa un moat
Per le startup AI che vendono in settori regolati (finance, sanità, pubblica amministrazione, energia, telco), la conformità all’AI Act diventerà rapidamente non solo un requisito ma un fattore di posizionamento. Il fornitore che arriva al cliente enterprise con una governance già strutturata, con documentazione tecnica pronta, con processi di audit interni, con conformità verificabile, parte da una posizione molto diversa rispetto al fornitore che propone una soluzione potente ma con governance ancora abbozzata. Il primo apre conversazioni, il secondo si ferma alla porta del compliance officer. E nei prossimi due anni, mentre le sanzioni dell’AI Act cominciano a entrare in pieno regime, questa differenza si amplificherà.
Vale la pena ricordare, per il contesto italiano, che la legge nazionale sull’intelligenza artificiale (Legge 132/2025) entrata in vigore il 10 ottobre 2025 si affianca al quadro europeo introducendo sanzioni che possono arrivare a circa settecentosettantacinquemila euro nei casi più gravi, oltre alle misure interdittive previste dal Decreto 231 (sospensione di autorizzazioni, esclusione da contributi pubblici, divieto di contrattare con la pubblica amministrazione). Il quadro italiano introduce anche un’aggravante specifica per i reati commessi con il supporto dell’AI, e una fattispecie penale per la diffusione illecita di contenuti AI-generated o alterati. Per le startup italiane che operano in settori sensibili, il quadro regolatorio nazionale rafforza ulteriormente la centralità della governance come fattore di posizionamento, oltre che come obbligo legale.
Le domande da fare a un fornitore AI
Il caso UnitedHealth con cui questa puntata ha aperto, e che probabilmente continuerà a produrre giurisprudenza nei prossimi anni, contiene già al suo interno la lezione che attraversa tutta la rubrica.
La tecnologia funzionava. Le metriche operative interne erano probabilmente coerenti con gli obiettivi di business. Il pilot era stato superato, l’adozione era andata avanti, il sistema era in produzione su volumi enormi. È mancato tutto il resto: la chiarezza sui confini di errore tollerabile, la presenza umana nei punti decisionali sensibili, la trasparenza verso il cliente finale, l’osservabilità interna che avrebbe permesso di intercettare il problema prima che fosse un giudice federale a dichiararlo. Ognuno di questi elementi, preso singolarmente, sembra un dettaglio operativo. Presi insieme, sono il discriminante tra un sistema che genera valore duraturo e un sistema che genera contenzioso miliardario.
Tre domande, da rivolgere a un fornitore AI prima di firmare un contratto in workflow sensibili, riassumono bene quanto detto. Cosa accade quando il sistema sbaglia, e chi risponde? Come è progettata la governance dell’escalation, e in quale punto del workflow l’umano resta nel loop? Quale livello di osservabilità avremo sui comportamenti del sistema, e con quali strumenti potremo ricostruire decisioni passate se necessario? Se il fornitore non sa rispondere a queste tre domande con precisione, il prodotto è probabilmente immaturo per un deployment in workflow sensibili, indipendentemente da quanto buona appaia la demo. La stessa terna di domande, applicata internamente da un team che sta costruendo un sistema AI, separa quelli che pensano alla governance fin dal seed round da quelli che la rinviano alla fase di scaling. Dove la prima categoria costruisce posizione, la seconda costruisce esposizione.
Con questa puntata si chiude il primo arco di questa rubrica. Le otto puntate hanno percorso il framework dal vertice (perché il vantaggio competitivo si è spostato dal modello al loop) fino al concreto (come si valuta una startup, come si esce dal pilot purgatory, come si progetta un wedge difendibile, come si costruisce fiducia operativa). Sono i tasselli di un ragionamento che, messi insieme, provano a dare una chiave di lettura strategica del momento di mercato dell’AI applicata. La trattazione completa del framework, con i sette loop, gli strumenti operativi, e l’appendice di scorecard e roadmap, è nel libro Da Zero a Loop. Da qui in poi la palla torna a chi costruisce e a chi finanzia chi costruisce, perché le idee, da sole, non costruiscono posizione. Costruiscono posizione le idee applicate con disciplina, ed è quello che mi auguro di aver dato strumenti per fare.
Partecipa alla community