C’è un’obiezione ragionevole a tutto il discorso sul ripensare processi e ruoli, e conviene prenderla sul serio perché nella maggior parte dei casi ha ragione. Chi propone di rivedere il processo sta quasi sempre proponendo di rallentare. Aggiunge un passaggio di approvazione, un documento da compilare, un comitato che si riunisce il giovedì, e lo fa nel momento peggiore, cioè quando una squadra ha finalmente trovato un ritmo. Ogni metodologia degli ultimi trent’anni si è presentata come qualità ed è stata consegnata come burocrazia. Le pagine di governance dell’intelligenza artificiale prodotte negli ultimi due anni sono in larga parte teatro, e servono a poter dire in un consiglio di amministrazione che il tema è presidiato. Se qualcuno arriva con una proposta di riassetto in mano, il sospetto è sano.
Un guasto che non solleva eccezioni
Quello che l’obiezione non copre è una classe di guasti che non produce errori. Non genera un ticket, non fa fallire una pipeline, non compare in nessuna dashboard. Il sintomo con cui si presenta non ha la forma di un incidente ma di una frase detta in retrospettiva, di solito verso il terzo o quarto mese di adozione di uno strumento agentico, quando qualcuno osserva che il modello è peggiorato.
La lettura naturale è che il fornitore abbia degradato qualcosa, o che l’entusiasmo iniziale fosse gonfiato. Quasi sempre non è andata così. È andata che il file di istruzioni del progetto è cresciuto fino a superare la soglia oltre la quale l’agente non riesce più a tenerlo tutto insieme, e ha cominciato a scartare in silenzio la metà che contava. Oppure che la descrizione di una procedura automatica è derivata di riformulazione in riformulazione fino a scattare su qualsiasi cosa, che equivale a non scattare più su niente. Nessuno dei due guasti solleva un’eccezione. Non esiste uno stack trace per un ponteggio che si sfalda, e in assenza di un errore la squadra attribuisce il calo allo strumento invece che alla propria impalcatura.
Lo statuto della configurazione personale
Questa è la prima manifestazione di un principio che, una volta visto, si riconosce in tre o quattro posti diversi della stessa azienda. Ciò che si degrada senza fare rumore è esattamente ciò che nessuno è tenuto a verificare.
Il codice applicativo ha una difesa contro il degrado silenzioso, e la difesa è che qualcuno ha scritto un test che si arrabbia. Le istruzioni con cui guidiamo un agente, i prompt salvati, le convenzioni di progetto, le automazioni che dovrebbero scattare da sole, tutto quel materiale che negli ultimi due anni è diventato infrastruttura di produzione, ha ereditato lo statuto della configurazione personale. Vive nella cartella di un progetto senza proprietario dichiarato, senza changelog, senza nessuno che risponda della sua manutenzione. Nella pratica significa che l’impalcatura più giovane e più fragile dell’intera catena di consegna è anche la sola che non abbiamo pensato di mettere sotto verifica.
La parola «fatto»
La seconda manifestazione riguarda una parola che in azienda diamo per definita e non lo è. La parola è «fatto». Un anno e mezzo di adozione di strumenti generativi ha accelerato molte cose, e una di quelle che ha accelerato più di tutte è la dichiarazione di completamento. Un agente arriva alla fine di un compito con una fiducia che non ha corrispettivo nella verifica, e la formula con cui chiude è indistinguibile da quella di un lavoro effettivamente concluso.
Se la definizione di fatto sta scritta in prosa, in una pagina di convenzioni interne che tutti hanno letto una volta, viene rispettata quando c’è tempo e saltata quando non c’è, cioè quando conta. Non viene saltata per negligenza. Viene saltata perché una regola in prosa competerà sempre, e sempre perdendo, con una consegna che ha una data. La differenza tra una regola scritta e un controllo deterministico che blocca la dichiarazione di completamento quando un file sorgente è cambiato dopo l’ultimo test passato non è una differenza di rigore. È la differenza tra un’intenzione e un vincolo, e sotto pressione sopravvive soltanto il secondo.
Nel frattempo il costo non è scomparso, si è spostato. Si è spostato sulla review, sul rework, sulla riapertura di attività già marcate come chiuse, e in nessuna di quelle tre voci qualcuno lo sta misurando, perché la metrica che guardiamo continua a essere la velocità con cui le cose vengono dichiarate concluse.
L’inventario che nessuno rigenera a metà sprint
La terza manifestazione è quella che conosco meglio, perché lavoro da anni con clienti in sanità e pubblica amministrazione dove la conformità non è un tema reputazionale ma una condizione di ammissibilità. La conformità normativa non fallisce per ignoranza. Nessuno, in nessuna azienda che abbia letto una gara negli ultimi tre anni, dubita che serva una distinta dei componenti software. Il punto è che nessuno la rigenera a metà sprint, perché nulla obbliga quel momento a esistere: c’è un rilascio da chiudere, e rigenerare l’inventario delle dipendenze compete con quel rilascio per l’attenzione di qualcuno e perde, ogni volta, fino al giorno in cui un auditor la chiede e non c’è. Ne ho scritto per esteso sostenendo che la compliance non fallisce per mancanza di norme, e da allora non ho trovato un solo controesempio.
Il guasto è identico ai due precedenti. Non è una lacuna di competenza, è l’assenza di un momento obbligato. La differenza è che qui l’orologio è pubblico e non negoziabile, perché gli obblighi di segnalazione delle vulnerabilità del Cyber Resilience Act si applicano dall’11 settembre 2026, il regolamento entra in pieno regime l’11 dicembre 2027, e l’European Accessibility Act è già in vigore dal 28 giugno 2025. L’attrito che fino a ieri costava una figura retorica in una riunione da adesso costa una non conformità.
Comprare capacità invece di diagnosticare
Vale la pena aggiungere una quarta occorrenza, più piccola ma diagnostica, perché mostra quanto facilmente si sbagli la cura. Quando una squadra comincia a battere contro i limiti di utilizzo degli strumenti agentici, la conclusione immediata è che serva un piano più capiente o un modello diverso. Nella grande maggioranza dei casi il fattore di costo non è il modello scelto, è il contesto accumulato in una sessione lunga, e la soluzione non sta nell’acquisto ma nel modo in cui il lavoro viene suddiviso.
È lo stesso errore in scala ridotta: davanti a un guasto invisibile compriamo capacità invece di diagnosticare il meccanismo, perché comprare capacità è un’azione che si può deliberare in dieci minuti e diagnosticare un meccanismo non lo è.
Chi sa dire no
Da qui in avanti la questione smette di essere tecnica e diventa una questione di ruoli, che è il motivo per cui la trovo interessante. Se il collo di bottiglia si sposta dalla produzione alla verifica, la risorsa scarsa non è più chi scrive in fretta. È chi sa dire no con una motivazione, e sa dirlo su un artefatto che ha tutta l’apparenza di essere corretto. È la stessa migrazione di valore che ho chiamato altrove debito di specifica, vista dal lato dell’uscita invece che dell’ingresso.
Nelle squadre piccole questo produce un effetto che ho visto da vicino: una persona junior affiancata da un agente consegna output con la superficie di un lavoro senior, senza il giudizio che di solito viene con quella superficie, e il carico di revisione si concentra su due o tre persone che diventano il vincolo di tutto il resto. La reazione istintiva è chiedere a quelle due o tre persone di rivedere più in fretta. La reazione giusta è chiedersi quale parte del loro giudizio era in realtà una regola che nessuno aveva mai scritto, e scriverla in una forma che si attivi da sola.
Formazione e pavimento sono due investimenti
È qui che formazione e baseline si separano, e vanno finanziate come due investimenti distinti perché rispondono a domande diverse. La formazione serve a elevare le persone, ad allargare quello che sanno vedere, a spostare qualcuno dal livello dell’esecuzione a quello della specifica e della verifica. Ma la formazione produce risultati sopra un pavimento, e in una squadra di dieci persone il pavimento non esiste per default. Esiste solo se qualcuno lo costruisce, lo mette sotto versionamento e lo tratta come un artefatto manutenuto invece che come una cartella di appunti.
Senza quel piano di sotto, l’elevazione delle persone resta un discorso da presentazione istituzionale: ognuno lavora al proprio livello di rigore, la varianza tra una consegna e l’altra dipende da chi l’ha presa in carico, e nessuno riesce a distinguere un miglioramento dovuto al metodo da un miglioramento dovuto a una singola persona particolarmente scrupolosa. Il pavimento non serve a limitare le persone brave. Serve a rendere visibile il loro contributo, che altrimenti si confonde con il rumore.
Quello che nessuna macchina può dichiarare valido
C’è un ultimo passaggio, e riprende il punto da cui sono partito qualche giorno fa scrivendo del livello che non si delega. Tutta questa architettura di verifiche automatiche ha un limite strutturale, e il limite è che nessuna di esse può dichiarare valido il proprio esito. Una macchina può inventariare, può generare, può segnalare una lacuna, può bloccare una dichiarazione di completamento. Quello che non può fare è marcare il proprio lavoro come accettato, conforme o validato, e non perché sia tecnicamente impossibile ma perché in quel gesto sta l’unica cosa che un ordinamento giuridico riconosce, cioè una persona che risponde. Su questo la regolazione europea ha smesso da tempo di essere un’opinione e si è messa a scrivere l’organigramma al posto nostro.
Il valore non sta nel produrre più artefatti, sta nel produrre evidenza al posto di fiducia. Un rapporto che per ogni voce dice presente, lacuna o non applicabile, con un puntatore o una motivazione, è utilizzabile in un contraddittorio. Un rapporto che dice che tutto sembra a posto non lo è, e la differenza tra i due non è di tono, è di ammissibilità.
Per questo ho messo la baseline che uso in open source con licenza MIT: tredici procedure più un controllo che, alla fine della sessione, blocca la dichiarazione di completamento quando un sorgente è cambiato dopo l’ultimo test passato. Ci sono i test che verificano le procedure, 1.111 controlli in diciannove suite, e un repository di prova costruito per fallire di proposito ogni superficie che l’audit dell’impalcatura controlla, perché un ponteggio di cui si afferma la solidità senza mostrarla ricade esattamente nella categoria di guasti che vuole prevenire. Sta su oltrematica.github.io/oltrematica-skills e chi vuole può contestarlo riga per riga, che è l’unico modo serio di offrire qualcosa del genere.
Due domande per il consiglio di amministrazione
Ma la parte che serve a un consiglio di amministrazione non è il repository. Sono due domande da mettere all’ordine del giorno della prossima riunione di direzione, e la loro utilità sta nel fatto che rispondere non richiede un’istruttoria.
La prima: chi, in azienda, è tenuto a verificare che il nostro ponteggio funzioni ancora, e con quale prova. La seconda: di quello che oggi chiamiamo fatto, quanto è tenuto insieme da un vincolo e quanto da un’intenzione. Se alla prima non corrisponde un nome e alla seconda non corrisponde un controllo, non è un problema di strumenti, e nessun acquisto lo risolverà.
Cosa ti porti a casa
Esiste una classe di guasti che non produce errori: un file di istruzioni cresciuto oltre la soglia di attenzione dell’agente, la descrizione di un’automazione derivata fino a scattare su tutto. Non c’è nessuno stack trace per un ponteggio che si sfalda, e in assenza di un errore la squadra incolpa il modello.
Ciò che si degrada senza fare rumore è esattamente ciò che nessuno è tenuto a verificare. Il codice applicativo ha una difesa contro il degrado silenzioso, e la difesa è un test che si arrabbia. Le istruzioni con cui guidiamo gli agenti hanno ereditato lo statuto della configurazione personale: nessun proprietario, nessun changelog, nessuna manutenzione.
Una definizione di «fatto» scritta in prosa competerà sempre con una consegna che ha una data, e perderà. Un controllo deterministico che blocca la dichiarazione di completamento quando un sorgente è cambiato dopo l’ultimo test passato non è più rigoroso: è un vincolo invece di un’intenzione, e sotto pressione sopravvive solo il vincolo.
Formazione e baseline sono due investimenti distinti. La formazione produce risultati sopra un pavimento, e in una squadra di dieci persone il pavimento non esiste per default: esiste se qualcuno lo costruisce, lo versiona e lo manutiene. Senza quel piano di sotto la varianza tra due consegne dipende da chi le ha prese in carico.
Nessuna verifica automatica può dichiarare valido il proprio esito, e non per un limite tecnico: in quel gesto sta l’unica cosa che un ordinamento riconosce, cioè una persona che risponde. Il valore non sta nel produrre più artefatti, sta nel produrre evidenza al posto di fiducia.
Domande e risposte
Perché è sano diffidare di chi propone di rivedere il processo?
Perché nella maggior parte dei casi chi propone di rivedere il processo sta proponendo di rallentare, e lo fa nel momento peggiore, quando una squadra ha finalmente trovato un ritmo. Ogni metodologia degli ultimi trent’anni si è presentata come qualità ed è stata consegnata come burocrazia, e buona parte delle pagine di governance dell’intelligenza artificiale prodotte negli ultimi due anni serve a poter dire in un consiglio di amministrazione che il tema è presidiato. Il sospetto è sano, semplicemente non copre i guasti che non producono errori.
Perché dopo qualche mese sembra che un agente sia peggiorato?
Quasi mai perché il fornitore ha degradato il modello. Più spesso il file di istruzioni del progetto è cresciuto fino a superare la soglia oltre la quale l’agente non riesce più a tenerlo tutto insieme, e ha cominciato a scartare in silenzio la metà che contava; oppure la descrizione di una procedura automatica è derivata di riformulazione in riformulazione fino a scattare su qualsiasi cosa, che equivale a non scattare più su niente. Nessuno dei due guasti solleva un’eccezione, e in assenza di un errore il calo viene attribuito allo strumento invece che all’impalcatura.
Che differenza fa un controllo deterministico rispetto a una regola scritta?
Una regola in prosa, per esempio una definizione di «fatto» in una pagina di convenzioni interne, viene rispettata quando c’è tempo e saltata quando non c’è, cioè quando conta. Non per negligenza: perché competerà sempre, e sempre perdendo, con una consegna che ha una data. Un controllo che blocca la dichiarazione di completamento quando un file sorgente è cambiato dopo l’ultimo test passato non è una differenza di rigore, è la differenza tra un’intenzione e un vincolo. Sotto pressione sopravvive soltanto il secondo, e il costo che sembra risparmiato si sposta su review, rework e riapertura di attività già chiuse.
Perché nessuno rigenera l'inventario delle dipendenze a metà sprint?
Non per ignoranza. Nessuna azienda che abbia letto una gara negli ultimi tre anni dubita che serva una distinta dei componenti software. Il punto è che nulla obbliga quel momento a esistere: c’è un rilascio da chiudere, e rigenerare l’inventario compete con quel rilascio per l’attenzione di qualcuno e perde, ogni volta, fino al giorno in cui un auditor lo chiede e non c’è. La differenza rispetto agli altri guasti è che qui l’orologio è pubblico: gli obblighi di segnalazione delle vulnerabilità del Cyber Resilience Act si applicano dall’11 settembre 2026, il regolamento entra in pieno regime l’11 dicembre 2027 e l’European Accessibility Act è in vigore dal 28 giugno 2025.
Perché formazione e baseline vanno finanziate separatamente?
Perché rispondono a domande diverse. La formazione serve a elevare le persone, ad allargare quello che sanno vedere, a spostare qualcuno dall’esecuzione alla specifica e alla verifica. Ma produce risultati sopra un pavimento, e in una squadra di dieci persone il pavimento non esiste per default: esiste solo se qualcuno lo costruisce, lo mette sotto versionamento e lo tratta come un artefatto manutenuto invece che come una cartella di appunti. Senza quel piano di sotto ognuno lavora al proprio livello di rigore e nessuno riesce a distinguere un miglioramento dovuto al metodo da un miglioramento dovuto a una singola persona scrupolosa.
L'autore
