Appunti sui limiti dell’efficienza nei sistemi automatici.
“Questo non è un articolo breve. È un percorso attraverso vent’anni di incidenti nei sistemi automatici. Chi progetta o governa sistemi complessi troverà qui strumenti, non opinioni.”
“Questo testo è pensato per chi progetta, governa o valuta sistemi complessi.”
Premessa
Nel 2012, un errore di configurazione in un algoritmo di trading della Knight Capital provocò la perdita di 440 milioni di dollari in 45 minuti. Il sistema continuò ad acquistare e vendere azioni a ritmo folle, generando ordini errati su 154 titoli. Nessuno riuscì a fermarlo in tempo. L’azienda cessò di esistere come entità indipendente pochi giorni dopo.
Nel 2020, un algoritmo di ammissione all’Università utilizzato in Inghilterra assegnò voti predittivi a decine di migliaia di studenti. Il modello penalizzò sistematicamente chi proveniva da scuole con performance storiche più basse, indipendentemente dal merito individuale. La protesta pubblica costrinse a fare marcia indietro, ma migliaia di giovani persero l’accesso all’università desiderata per mesi. Alcuni per sempre.
Cosa hanno in comune questi due episodi, così diversi per settore, tecnologia, conseguenze? In entrambi, l’errore non fu l’unico problema. Il problema fu che l’errore si moltiplicò. Le pagine che seguono raccolgono appunti, osservazioni, frammenti emersi dall’analisi di casi come questi. Non c’è una tesi unitaria, né un metodo. Ci sono storie, variabili che ricorrono, modi in cui organizzazioni diverse hanno affrontato problemi simili. Il lettore ne faccia l’uso che crede.
Capitolo 1 – L’efficienza come idolo
Negli ultimi vent’anni, lo sviluppo tecnologico è stato guidato da un obiettivo dominante: rimuovere ogni forma di attrito. Processi più veloci, decisioni più autonome, automazione spinta sono diventati indicatori di progresso. Un sistema che processa mille richieste al secondo è considerato migliore di uno che ne processa cento. Un algoritmo che sostituisce l’intervento umano è visto come evoluzione naturale.
Questa spinta ha prodotto risultati importanti. Ma ha anche introdotto un presupposto tacito: che l’efficienza sia sempre un valore positivo.
Alcuni osservatori hanno cominciato a dubitarne. Un motore potente senza freni non è un progresso, è un pericolo, notava un ingegnere intervistato dopo il crollo di Knight Capital. La stessa proprietà che in condizioni normali produce risultati rapidi, in condizioni di errore produce errori rapidi, amplificati, difficili da contenere.
Il punto non è rinunciare all’efficienza. È riconoscere che ha senso solo entro confini. Quando l’accelerazione non incontra freni, il rischio non è l’errore in sé, ma la velocità con cui l’errore diventa sistema.
Questa non è una legge, solo un’osservazione ricorrente.
Capitolo 2 – L’errore che si moltiplica
Per capire cosa significhi progettare confini, può essere utile osservare come si comporta l’errore in ambienti automatici.
Nei processi manuali e analogici, l’errore umano aveva una caratteristica fondamentale: era circoscritto. Una decisione sbagliata richiedeva tempo per propagarsi, incontrava resistenze fisiche e organizzative, lasciava tracce che consentivano correzioni prima che il danno si consolidasse.
Nei processi digitali, questa dinamica cambia. Quando un sistema automatico opera sulla base di un parametro errato o di un bias non intercettato, non produce un singolo effetto anomalo: produce centinaia, migliaia, talvolta milioni di effetti identici e simultanei. L’errore non è più artigianale, diventa industriale.
Un caso emblematico: nel 2018, un algoritmo di reclutamento di una grande azienda tecnologica fu scoperto penalizzare sistematicamente i curriculum femminili. Il modello era stato addestrato su dati storici che riflettevano assunzioni prevalentemente maschili. L’errore non fu una singola decisione sbagliata, ma un’intera classe di decisioni replicate automaticamente per mesi. Quando fu scoperto, migliaia di candidature erano già state scartate ingiustamente.
La replica, non l’errore, fu il problema.
Capitolo 3 – Variabili che riemergono
Analizzando incidenti in settori diversi, alcuni elementi tornano con frequenza. Il tempo necessario per rallentare un’azione in corso: in alcuni sistemi di trading si misura in millisecondi, in processi amministrativi automatizzati può essere di giorni. L’estensione del danno possibile prima di un intervento: un sistema di credit scoring che processa 100 richieste al minuto e impiega 30 minuti per attivare un controllo espone 3.000 richieste all’errore. La possibilità di correggere dopo l’accaduto: un errore in una transazione finanziaria può essere corretto entro pochi giorni, un errore in una diagnosi assistita da intelligenza artificiale ha una finestra molto più stretta. L’opacità tecnica del sistema: in alcuni casi, gli stessi progettisti faticano a spiegare perché un modello ha preso una certa decisione.
In alcuni casi tornano sempre gli stessi dettagli; in altri cambiano del tutto.
Capitolo 4 – Cinque contesti, cinque problemi
Vale la pena esaminare rapidamente alcuni ambiti in cui l’automazione produce rischi significativi. Non per trarre conclusioni generali, ma per mostrare come le stesse variabili si presentano in forme diverse.
Trading algoritmico
Qui il tempo è l’elemento critico. I sistemi operano in millisecondi, e un errore può bruciare centinaia di milioni in pochi minuti. La possibilità di correggere dopo è quasi nulla: dopo pochi secondi, le transazioni sono già eseguite. Il controllo umano diretto è impossibile. Le contromisure tipiche sono automatiche: meccanismi che interrompono le operazioni quando certi indicatori superano soglie.
Un gestore di un fondo intervistato qualche anno fa raccontava: “Abbiamo imparato a progettare l’arresto automatico come prima linea. L’umano arriva dopo, per capire cosa è successo, non per prevenirlo.”
Credit scoring
Qui il tempo è più lungo – ore o giorni – ma l’estensione è enorme. Un modello errato può negare credito a decine di migliaia di persone prima di essere corretto. La correggibilità si misura in giorni o settimane, ma il danno reputazionale può essere permanente. Il controllo umano è teoricamente possibile, ma spesso inefficace perché gli operatori non hanno visibilità sul funzionamento del modello.
Un responsabile conformità di una banca europea osservava: “Scopriamo gli errori quando ormai migliaia di clienti hanno già subito un torto. Possiamo rimborsare, ma la fiducia è persa.”
Triage sanitario automatizzato
In alcuni sistemi sanitari, algoritmi aiutano a stabilire priorità d’accesso alle cure. Qui il tempo può essere di minuti o ore, ma l’estensione si misura in vite umane. La correggibilità è stretta: un paziente mal classificato può ricevere cure tardive con conseguenze permanenti. Il controllo umano è cruciale ma spesso esercitato in condizioni di stress e informazioni limitate.
Un medico coinvolto in un progetto di triage algoritmico raccontava: “Il sistema mi dà una priorità. Se voglio cambiarla, devo motivare, e la motivazione richiede tempo che non ho. Alla fine, la lascio quasi sempre com’è, anche quando ho dubbi.”
Deploy automatico in infrastrutture IT
Le pipeline di rilascio del software sono sempre più automatizzate. Un errore in una configurazione può bloccare l’intera piattaforma in pochi secondi. L’estensione è sistemica. La correggibilità dipende dalla qualità dei meccanismi di ritorno: se esistono e sono testati, si può tornare indietro in minuti; altrimenti, il danno si prolunga.
Un incidente noto: nel 2017, un errore in un aggiornamento di Amazon Web Services causò il blocco di migliaia di siti per ore. Il rollback automatico non funzionò come previsto. L’azienda impiegò ore per ripristinare manualmente.
Graduatorie algoritmiche nel settore pubblico
Dall’assegnazione di posti all’università alla distribuzione di benefici sociali, sempre più decisioni pubbliche sono automatizzate. Qui il tempo è lento – giorni o settimane – ma l’estensione è sociale e giuridica. La correggibilità può essere ampia, ma ogni giorno di errore produce ingiustizie concrete. Il controllo umano è spesso previsto dalle norme, ma raramente esercitato per mancanza di competenze o paura di responsabilità.
Il caso inglese del 2020 è solo l’esempio più noto di un fenomeno più ampio, che riguarda molti paesi.
Capitolo 5 – I limiti del controllo dopo i fatti
Di fronte a questi rischi, molte organizzazioni investono in audit, monitoraggi, verifiche successive. Sono strumenti necessari, ma in alcuni casi si è visto che non bastano.
Il problema è temporale. Se la verifica arriva dopo l’esecuzione, il danno si è già prodotto. Nel caso di errori scalabili, si è moltiplicato. L’audit può identificare le cause, suggerire correzioni, attribuire responsabilità. Ma non può cancellare gli effetti già prodotti.
Un caso tra molti: nel 2016, un errore in un algoritmo di determinazione dei premi assicurativi portò a sovrafatturare centinaia di migliaia di clienti per oltre un anno. L’audit interno scoprì l’errore, ma i clienti avevano già pagato premi eccessivi, e recuperarli richiese mesi di lavoro e contenziosi. Il danno economico e reputazionale era già avvenuto.
Questo non significa che gli audit siano inutili. Significa che in certi contesti non possono essere l’unico presidio.
Capitolo 6 – Punti di rallentamento
In alcuni processi si incontrano punti in cui il flusso automatico viene rallentato e subordinato a una verifica esplicita. Non sono una soluzione universale, ma in certi casi hanno funzionato.
La loro efficacia sembra dipendere da alcune condizioni. Quando la stessa persona o gruppo progetta, implementa e autorizza un’azione critica, si crea una concentrazione di responsabilità che in alcuni incidenti ha giocato un ruolo. La separazione delle funzioni – chi costruisce non è l’unico a poter osservare – introduce un controllo incrociato che può ridurre certi rischi. Chi osserva deve poter capire cosa sta osservando: non serve che possegga la stessa profondità tecnica del progettista, ma deve disporre di rappresentazioni intelligibili del rischio, delle alternative, delle conseguenze. In alcuni casi, operatori che firmavano senza comprendere sono stati un anello debole. Non tutte le situazioni hanno lo stesso grado di prevedibilità: in alcuni contesti, quando l’incertezza supera una certa soglia – per novità del caso, per complessità, per valore in gioco – l’esecuzione automatica viene differita. L’incertezza non viene rimossa, ma gestita attraverso un passaggio deliberativo. L’osservazione finale, in alcune organizzazioni, è associata a una persona identificabile, non a un ruolo astratto. Questo non per attribuire colpe, ma per rendere visibile che qualcuno, in quel momento, ha condiviso la responsabilità della decisione.
Senza queste condizioni, i punti di rallentamento rischiano di diventare rituali. Presenti sulla carta, assenti nella sostanza.
Capitolo 7 – Quando il controllo peggiora le cose
Non sempre introdurre controlli aggiuntivi produce effetti positivi. In alcuni casi, l’attrito ha generato nuovi rischi.
Un esempio viene dal settore aeronautico. Dopo una serie di incidenti, furono introdotti checklist e doppi controlli obbligatori per ogni procedura critica. Il risultato fu un aumento dei carichi di lavoro dei piloti, che in situazioni di emergenza si trovavano a gestire decine di verifiche invece di concentrarsi sul problema principale. In alcuni incidenti simulati, i piloti con più checklist commisero più errori di quelli con meno vincoli.
In un contesto molto diverso, una piattaforma di e-commerce introdusse un sistema di approvazione manuale per tutte le transazioni superiori a una certa soglia, pensando di ridurre le frodi. Il risultato fu un collo di bottiglia che rallentò le consegne, danneggiando i venditori legittimi e spingendo i clienti verso concorrenti. Le frodi, intanto, si spostarono su transazioni di importo appena inferiore alla soglia.
Un altro caso: in un ospedale, fu introdotto un sistema di doppia firma per tutte le prescrizioni farmacologiche, per ridurre gli errori. Il sistema funzionava bene in condizioni normali, ma in emergenza – quando i minuti contavano – i medici iniziarono a firmare senza leggere, pur di non rallentare le cure. L’errore aumentò, non diminuì.
Questi episodi suggeriscono che l’attrito va calibrato, non massimizzato. Ma come si calibra, nessuno lo sa con certezza.
Capitolo 8 – Sistemi senza centro
I punti di rallentamento funzionano meglio in processi lineari, dove c’è un flusso identificabile da osservare. Ma molti sistemi contemporanei – orchestrazioni di microservizi, reti di agenti AI, piattaforme decentralizzate – non hanno un centro. Le decisioni emergono dall’interazione di nodi autonomi.
In questi contesti, l’idea di un punto di arresto va ripensata. Non esiste un interruttore centrale. Alcuni hanno sperimentato protocolli di coordinamento che introducono attrito distribuito.
In certi progetti blockchain, ad esempio, le transazioni ad alto valore richiedono firme multiple prima di essere eseguite. In alcuni sistemi di agenti AI, le intenzioni vengono pubblicate su un registro accessibile, e altri agenti hanno una finestra temporale per opporsi.
Non si tratta di fermare il sistema, ma di frammentare le interazioni critiche abbastanza da consentire un controllo diffuso. Il tempo di risposta diventa il tempo per raggiungere il consenso. L’estensione del danno è limitata dalla necessità di coordinamento.
Un ricercatore che lavora su questi temi osservava: “Non cerchiamo un interruttore. Cerchiamo regole di interazione che rendano gli errori meno esplosivi.”
Capitolo 9 – Quando rallentare non è possibile
Esistono contesti in cui il rallentamento sincrono è impraticabile. Nel trading ad alta frequenza, rallentare il sistema significa uscire dal mercato con perdite certe. Nel controllo di reti elettriche, ritardare l’erogazione causa blackout.
In questi casi, l’attenzione di alcuni progettisti si è spostata dall’interruzione al contenimento.
In certi sistemi di pagamento, le transazioni oltre una certa soglia vengono marcate come “reversibili” per alcuni secondi. Se in quella finestra un operatore segnala un’anomalia, la transazione viene automaticamente annullata. Se nessuno interviene, diventa definitiva.
In alcuni contesti industriali, si usano limiti di velocità o volume: il sistema può operare, ma non può superare certe soglie, anche se tecnicamente potrebbe farlo. In questo modo, l’estensione del danno potenziale è contenuta.
In altri ancora, si attivano notifiche prioritarie mentre l’esecuzione prosegue, ma con vincoli di sicurezza. L’operatore viene informato, ma il sistema continua a funzionare, magari in modalità ridotta.
Un ingegnere di una piattaforma di trading spiegava: “Non possiamo permetterci di rallentare tutto. Ma possiamo permetterci di limitare, di avvisare, di rendere reversibile.”
Capitolo 10 – I costi, in vari contesti
I meccanismi descritti hanno costi, che in alcune organizzazioni sono emersi chiaramente.
Costi operativi: rallentamento di alcune operazioni, introduzione di passaggi aggiuntivi, necessità di personale dedicato.
Costi organizzativi: formazione, progettazione dei checkpoint, gestione delle eccezioni.
Costi culturali: resistenze in ambienti abituati a considerare l’automazione come valore assoluto.
Costi di implementazione: sviluppo e manutenzione dei meccanismi stessi.
In alcuni contesti – errori facilmente reversibili, impatto trascurabile – questi costi possono superare i benefici. In altri – errori costosi, socialmente rilevanti, giuridicamente contestabili – l’assenza di meccanismi di controllo è stata, in retrospettiva, una scelta costosa.
Un dirigente di un’azienda finanziaria, dopo un incidente, commentava: “Avevamo risparmiato su un sistema di controllo. Pensavamo fosse inefficienza. Poi l’incidente ci è costato dieci volte quello che avremmo speso.”
Capitolo 11 – L’accumulo di controlli
Un fenomeno osservato in alcune organizzazioni complesse è la stratificazione dei controlli nel tempo. Ogni crisi, ogni audit, ogni nuova normativa aggiunge un checkpoint. Il risultato può essere paralisi, non governo.
L’eccesso di controlli genera due effetti:
-
in alcuni casi, troppi punti di osservazione diventano tutti ugualmente importanti, e quindi nessuno lo è veramente. Gli operatori imparano a procedere meccanicamente.
-
in altri, si sviluppano scorciatoie, procedure parallele, “eccezioni” che svuotano i checkpoint della loro sostanza.
Un responsabile della conformità in una grande azienda raccontava: “Abbiamo così tanti controlli che nessuno li prende più sul serio. Sono solo ostacoli da superare. La sostanza è evaporata.”
Per questo, in alcuni contesti si è cominciato a interrogarsi periodicamente sull’effettiva utilità di ogni controllo. Non come procedura formale, ma come pratica riflessiva.
Capitolo 12 – Chi paga l’errore
Un’ultima osservazione ricorrente riguarda la distribuzione del rischio. Quando un sistema automatico produce un danno, il costo non è sopportato solo dall’organizzazione che lo ha progettato. È sopportato da clienti, utenti, cittadini, talvolta dall’intera collettività.
Questa asimmetria – chi produce il rischio e chi ne subisce le conseguenze – ha cominciato a interessare regolatori e legislatori. Il Regolamento AI Act europeo, ad esempio, richiede per i sistemi ad alto rischio una sorveglianza umana efficace, non formale.
Un funzionario europeo coinvolto nella stesura del regolamento osservava: “Non vogliamo imporre soluzioni tecniche. Vogliamo che chi progetta sistemi si ponga domande. Le risposte possono essere diverse. Ma le domande sono necessarie.”
Capitolo 13 – La difficoltà di osservare
Il vero ostacolo all’introduzione di meccanismi di osservazione efficaci, in molte esperienze, è stato culturale, più che tecnico.
Un meccanismo che può rallentare l’esecuzione viene percepito come ostacolo, fastidio. Fino al momento in cui non evita un danno evidente, la sua utilità rimane astratta, mentre il suo costo è concreto e immediato. In questa asimmetria, la tendenza naturale è aggirarlo, renderlo formale, svuotarlo di sostanza.
Un fenomeno più subdolo è l’automazione dell’osservazione. In alcune organizzazioni, i “controlli umani” sono in realtà sistemi semi-automatici. L’operatore deve approvare in pochi secondi, senza tempo per valutare, su schermate poco chiare. La pressione sistemica – obiettivi di produttività, code interminabili, paura di rallentare i colleghi – trasforma l’osservazione in un passaggio formale. Si produce così l’illusione del governo: un artefatto che soddisfa gli auditor, ma non offre protezione reale.
Un operatore intervistato in una banca raccontava: “Devo approvare centinaia di operazioni al giorno. Ho tre secondi per ciascuna. Se blocco, mi chiedono perché. Alla fine, clicco e basta.”
Capitolo 14 – Quando l’osservazione produce conoscenza
In alcuni casi, i punti di osservazione hanno prodotto effetti positivi inattesi. Quando sono ben progettati, introducono un elemento di confronto tra la logica del sistema e la valutazione umana. Questo confronto, in alcune organizzazioni, ha generato apprendimento: ha permesso di identificare i limiti del modello, le situazioni non previste, le assunzioni implicite che necessitavano revisione.
Un responsabile IT raccontava: “All’inizio, le attivazioni del nostro meccanismo di blocco erano viste come fallimenti. Poi abbiamo cominciato a studiarle. Erano dati su come il sistema si comportava in situazioni che non avevamo previsto. Abbiamo migliorato il sistema grazie a quelle eccezioni.”
In questa prospettiva, ogni attivazione di un controllo non è un fallimento, ma un’informazione. Organizzazioni che imparano a leggere in questo modo le eccezioni tendono a sviluppare sistemi più robusti nel tempo.
Capitolo 15 – Esempi, non pattern
Dall’osservazione di pratiche in diversi settori emergono alcuni meccanismi ricorrenti. Non sono l’unica possibilità, né costituiscono un catalogo. Sono solo esempi di ciò che in alcuni contesti è stato fatto.
In alcuni sistemi di trading, si usano interruzioni automatiche su soglia: il sistema monitora condizioni operative e al superamento di una certa soglia interrompe l’esecuzione per un periodo.
In molte piattaforme digitali, si usano limiti di velocità o volume: un tetto alla frequenza o al volume cumulato delle operazioni. Superato il limite, le richieste vengono rifiutate o accodate.
In contesti ad alto impatto, si usa l’approvazione multipla: azioni critiche richiedono il consenso di più soggetti. L’esecuzione avviene solo al raggiungimento di un numero minimo di approvazioni.
Nel rilascio di software, si usa il rilascio graduale: le modifiche vengono distribuite inizialmente a un sottoinsieme limitato di utenti. Dopo verifica, si procede incrementando la percentuale.
In alcune organizzazioni, si usa la finestra di osservazione: l’intenzione di eseguire un’azione viene annunciata pubblicamente. Segue una finestra temporale in cui soggetti abilitati possono osservare e segnalare problemi.
In contesti critici, si usa l’esecuzione condizionata al rollback: l’azione viene eseguita solo se esiste un meccanismo di ritorno testato e praticabile.
In quasi tutti i contesti regolamentati, si usa la registrazione non alterabile: tutte le autorizzazioni, le attivazioni di checkpoint, le decisioni vengono registrate in modo non modificabile.
In alcuni sistemi ad alta incertezza, si usa la modalità degradata: in condizioni di incertezza, il sistema riduce automaticamente le proprie funzionalità a un sottoinsieme sicuro.
Questi sono solo esempi. Non c’è una gerarchia, non c’è una tassonomia. Sono strumenti che in certi contesti hanno funzionato, in altri no.
Capitolo 16 – Scegliere, caso per caso
La scelta tra questi meccanismi dipende dal contesto e dalle priorità. Non esiste una ricetta.
In una discussione tra progettisti, qualcuno osservò: “Se il rischio principale è la velocità di propagazione, forse servono meccanismi automatici come le interruzioni su soglia. Se invece il problema è l’errore umano, l’approvazione multipla può aiutare. Ma dipende sempre da quanto tempo hai, da quanto è grave l’errore, da chi può osservare.”
Un altro aggiunse: “E se non puoi rallentare, allora devi pensare a come rendere reversibile, o a come limitare. Ma sono scelte, non verità.”
In sistemi complessi, più meccanismi possono coesistere. L’importante è che ciascuno abbia una giustificazione chiara, e che l’insieme non diventi un accumulo paralizzante.
Un consulente con esperienza in vari settori osservava: “Non esiste la configurazione giusta. Esiste la configurazione che ti sei preso il tempo di pensare, e che sei disposto a rivedere quando le cose cambiano.”
Capitolo 17 – Un percorso accidentato
In una grande azienda di servizi finanziari, dopo un incidente, cominciarono a lavorare su questi temi. Ma il percorso non fu lineare come si potrebbe immaginare.
Prima ancora di aver completato la mappatura dei processi critici, qualcuno in un team tecnico aveva già introdotto un limite di velocità su alcune API, ispirato da un articolo letto online. Funzionò bene, e altri team copiarono la soluzione senza attendere direttive centrali.
Quando arrivarono a definire le soglie di tolleranza – il danno massimo accettabile, il tempo massimo per reagire – scoprirono che in alcuni processi le soglie erano già state implicitamente fissate da anni, nei contratti con i clienti o nelle prassi operative. Dovevano solo esplicitarle.
La selezione dei meccanismi avvenne in parallelo, con approcci diversi in unità diverse. Alcuni adottarono l’approvazione multipla, altri il rilascio graduale, altri ancora misero tutto in un registro immutabile senza modificare i processi. Solo dopo alcuni mesi si accorsero che stavano usando soluzioni diverse per problemi simili, e organizzarono un confronto.
L’implementazione graduale, che pensavano di fare in sequenza, divenne un patchwork di sperimentazioni locali. Alcune fallirono, altre ebbero successo, e le soluzioni migliori si diffusero per imitazione, non per pianificazione.
La formazione, che avevano programmato dopo l’implementazione, fu anticipata dalle richieste degli operatori, che cominciarono a fare domande sui nuovi meccanismi prima ancora che fossero spiegati.
Alla fine, dopo qualche anno, avevano un insieme eterogeneo di pratiche, nessuna delle quali era stata “progettata” centralmente. Funzionava, ma nessuno avrebbe saputo scrivere un manuale su come ci erano arrivati.
Un dirigente coinvolto nel processo commentava: “Se dovessi rifarlo, non saprei da dove cominciare. È successo e basta.”
Capitolo 18 – Dalle idee ai meccanismi
Esiste una differenza importante tra un’idea e un meccanismo operativo. Un’idea descrive come si dovrebbe decidere. Un meccanismo operativo introduce un passaggio che influenza l’esecuzione. Non suggerisce, non raccomanda, non auspica. Condiziona.
I meccanismi descritti nel capitolo 15 diventano operativi quando sono implementati in codice, in procedure, in architetture. La loro presenza è verificabile. La loro assenza è ugualmente verificabile.
Per regolatori, assicuratori, magistrati, ciò che conta non è se il processo fosse ben pensato, ma se fosse governato nella pratica. Chiedono tracce, log, evidenze.
Un funzionario di vigilanza, intervistato sulle procedure ispettive, raccontava: “A volte chiediamo esempi recenti di operazioni bloccate e perché. Non sempre ci sono risposte.”
Capitolo 19 – Ambiguità
Forse il problema non è tecnico. Forse è politico, nel senso più ampio del termine.
La decisione su quanto rallentare un sistema, su quali errori accettare, su chi debba sopportare il costo dell’incertezza – sono scelte che implicano una visione del mondo, un’idea di giustizia, una gerarchia di valori.
In alcuni contesti, l’automazione totale ha funzionato meglio. Le piattaforme di social media, con i loro filtri automatici, processano miliardi di contenuti al giorno con tassi di errore bassissimi. I pochi errori che commettono – un post cancellato ingiustamente, uno lasciato online quando andrebbe rimosso – sono il prezzo di una scala altrimenti ingovernabile.
In altri contesti, lo stesso approccio è stato disastroso. La differenza non sta nella tecnologia, ma in cosa è in gioco. Un post cancellato è diverso da un prestito negato, che è diverso da una diagnosi sbagliata.
Forse non esiste una soluzione. Forse esistono solo compromessi, e l’arte sta nel riconoscerli caso per caso, senza illudersi di aver trovato la formula giusta.
Un filosofo della tecnologia, in un convegno, osservava: “Ci comportiamo come se il problema fosse progettare sistemi che non sbagliano. Ma il problema è decidere, collettivamente, quali errori siamo disposti a tollerare e quali no. Questa non è una domanda tecnica. È una domanda politica. E finché continueremo a trattarla come tecnica, continueremo a sbagliare.”
Capitolo 20 – Confini, non ricette
Le pagine che precedono hanno attraversato casi, variabili, meccanismi, resistenze. Non offrono una teoria compatta, né un insieme di prescrizioni. Offrono domande, strumenti, esempi.
In una conversazione tra progettisti, emerse una riflessione: “Forse la domanda non è ‘esiste un momento in cui possiamo rallentare?’. Forse la domanda è ‘in quali momenti ha senso rallentare, e in quali no?’. O forse è ‘chi decide dove rallentare?’. O forse è ‘come facciamo a sapere se stiamo rallentando nel posto giusto?’.”
Nessuno aveva una risposta.
Un ricercatore che ha studiato a lungo questi fenomeni osservava: “La maturità di un’organizzazione, forse, non si misura dalla completezza del suo sistema di controllo. Si misura dalla qualità delle domande che si pone, e dalla capacità di adattare le risposte alla varietà delle situazioni.”
Un processo che non può essere rallentato non è efficiente. È esposto. Ma un processo pieno di rallentamenti inutili non è governato, è paralizzato. Il punto non è massimizzare l’attrito, ma scegliere dove metterlo, quanto farne, come mantenerlo nel tempo.
In un’epoca in cui l’automazione si estende a decisioni sempre più sensibili – finanziarie, sanitarie, giuridiche, sociali – questa capacità di scelta non è un lusso. È parte della responsabilità di chi progetta e gestisce sistemi che incidono sulla vita delle persone.
Nota finale
Questo testo raccoglie osservazioni e strumenti emersi dall’analisi di incidenti in diversi settori. Può essere utilizzato come base per discussioni, valutazioni, progettazioni. Non pretende completezza, né offre un modello. Offre un linguaggio e alcuni punti di partenza. Il lettore ne faccia l’uso che crede, consapevole che ogni contesto è diverso, e che le soluzioni vanno trovate caso per caso, non importate da altri.
Salvatore Martino
