McKinsey 2026: la fiducia in IA sale a 2,3. La mia infrastruttura non ci crede ancora.

McKinsey ha appena pubblicato la sua indagine annuale sulla maturità della fiducia in IA, stavolta inquadrata come l'era agentica. Circa 500 organizzazioni intervistate tra dicembre 2025 e gennaio 2026. Punteggio medio di maturità: 2,3 su 5, leggermente sopra il 2,0 dell'anno precedente. Il 62% sperimenta con agenti, il 23% li scala da qualche parte. E il titolo che mi interessa davvero: quasi due terzi degli intervistati citano sicurezza e rischio come prima barriera allo scaling dell'IA agentica, davanti perfino all'incertezza regolatoria.

Quel numero è ciò che dovrebbe atterrare su qualunque roadmap di piattaforma questo trimestre. Da dove lavoro io — DevOps e infrastruttura per aziende che devono difendere il proprio stack davanti a un regolatore — il messaggio del rapporto non è ottimista. È una lista di cose che non sono ancora montate sotto le belle slide della keynote.

L'inquadramento di McKinsey: la fiducia non è più compliance, è valore di business

L'angolo di quest'anno è deliberato. McKinsey dice che l'influenza percepita di alcuni framework regolatori è scesa e che le aziende passano da una motivazione compliance-led a una value-driven. Traduco: i dirigenti vogliono smettere di vedere la governance dell'IA come un costo obbligato e iniziare a vederla come una leva di revenue.

Mi va bene come cornice di discorso. Mi sembra tossica come cornice operativa se non capisci cosa c'è sotto. La parte che il rapporto cita — che le organizzazioni con oltre 25 milioni di dollari investiti in responsible AI hanno impatti di EBIT superiori al 5% — non è perché la governance "aggiunga valore" per magia. È perché le aziende che hanno messo quel denaro hanno anche costruito:

• Pipeline di valutazione con golden set versionati.
• Attribuzione di costo per agente e per rotta.
• Cataloghi di strumenti con scope e quote per agente.
• Un team di piattaforma IA con on-call proprio.
• Lineage di prompt, modelli, embedding, retrieval e decisioni.

Se il tuo CFO vede il numero del 5% e deduce che la governance paga, perfetto. Ma che nessuno confonda la conclusione: ciò che paga è l'infrastruttura. La governance è ciò che la rende difendibile. Senza la prima non hai prodotto; senza la seconda non hai licenza di esercizio.

Il 23% che "scala agenti" è più piccolo di quanto sembri

L'altra cifra che circolerà in molte presentazioni di comitato questo mese è che il 23% delle aziende scala già agenti da qualche parte. Letta alla lettera, è una pietra miliare. Letta da ingegnere che deve stabilizzare quei sistemi, è una domanda:

Scalati come? Con quali SLO? Sotto quale classificazione di rischio? Con quale piano di incidente?

Il rapporto è abbastanza onesto da dire che solo circa un terzo delle organizzazioni riporta livelli di maturità di 3 o superiore in governance, strategia e governance specifica degli agenti. La distanza tra "23% scala agenti" e "33% ha governance di livello 3" è esattamente lo spazio dove vivranno i prossimi incidenti di IA che usciranno sulla stampa.

In ambienti regolamentati — banca, sanità, energia, settore pubblico — quella distanza non è un rischio teorico. È un gap che un supervisore può chiudere con una richiesta. La domanda che faccio a qualsiasi team voglia scalare agenti in questi settori è la stessa che farebbe un esaminatore della BCE o dell'OCC: mostrami le prove.

Il 65% contro il 23%: la differenza è human-in-the-loop fatto bene

Uno dei dati più utili del rapporto è il divario tra high performer e il resto sulla validazione umana: il 65% dei leader ha processi definiti di human-in-the-loop, contro il 23% in coda. Qui il rapporto descrive correttamente un fenomeno che vedo ogni settimana negli audit tecnici: la differenza tra un sistema di IA che regge una revisione interna e uno che non la regge è, quasi sempre, il rigore del livello umano, non la qualità del modello.

Ma human-in-the-loop è un'etichetta che nasconde quattro disegni molto diversi:

1. HITL di approvazione esplicita — l'agente propone, l'umano firma. È il pattern che un regolatore capisce senza traduzioni. Lento, ma difendibile.
2. HITL per eccezione — l'agente decide in autonomia sotto una soglia di confidenza, l'umano entra quando viene superata. Richiede un confidence estimator calibrato. Molti team usano qui la probabilità grezza del logit come proxy, e non lo è. Calibra o muori.
3. HITL post-hoc — l'umano rivede un campione statistico a posteriori. Utile per il drift detection, insufficiente come controllo primario in settori regolamentati.
4. HITL teatrale — c'è un umano nel workflow, ma il suo ruolo reale è premere approva su batch da 200 perché la coda avanza troppo veloce. Non è governance, è assoluzione con la tastiera. Esce al primo audit serio.

Quando parliamo con un cliente del 65%, quasi sempre usa un mix calibrato di 1 e 2 con un campionamento statistico del 3. Quando parliamo con uno del 23%, quasi sempre sta al 4 senza saperlo. Quella è la differenza vera, ed è architetturale prima che culturale. C'è un lungo capitolo che ho già scritto sul tema che il mio io del passato deve continuare a predicare.

"Fare la cosa sbagliata" è un problema nuovo per il runbook

McKinsey introduce una distinzione che vale la pena rubare così com'è: nell'era agentica le aziende non si devono più preoccupare solo dei sistemi che dicono la cosa sbagliata, ma dei sistemi che fanno la cosa sbagliata — che prendono azioni non desiderate, fanno cattivo uso degli strumenti o operano fuori dalle guardrail.

Quel cambio è ciò che rompe la maggior parte dei runbook che vedo nei clienti che vengono dall'era chatbot. Tutta la disciplina di osservabilità costruita attorno a latenza, error rate, throughput resta necessaria, ma non è sufficiente. Serve un secondo asse di monitoring:

• Inventario degli strumenti disponibili per agente, con scope, rate limit e destinazioni permesse. Se l'agente A può toccare Salesforce, l'agente B non dovrebbe poterlo usare transitivamente via delegation.
• Quote di costo e di azione per agente e per finestra temporale. Un loop infinito di un agente che chiama un'API esterna è un incidente di finance prima di essere uno di SRE.
• Allarmi di comportamento, non solo di errore: l'agente che fino a ieri faceva una cosa e oggi ne fa un'altra contro dati reali — anche se tecnicamente non fallisce — è il segnale di incidente proprio di quest'era.
• Audit trail firmato di ogni azione di strumento eseguita, non solo dei messaggi del modello. In un ambiente regolamentato, chi ha fatto cosa contro il mio sistema di registrazione è la domanda dell'esaminatore, non cosa ha detto l'LLM.

Se il tuo stack non genera questo secondo flusso, non stai facendo girare agenti in produzione. Stai facendo girare una demo con permessi elevati. La distanza tra le due cose la pagherai con un incidente, con un titolo o con una multa, in quest'ordine.

Cosa cambia esattamente in un ambiente regolamentato

Il rapporto parla dell'EU AI Act e dell'orizzonte di tre anni fino al pieno dispiegamento. Cita correttamente che un approccio conservativo — anticipare standard probabili su supervisione umana, protezione dei dati ed equità — aiuta le aziende ad andare avanti. Sottoscrivo. E aggiungo, dall'ingegneria, cosa significa "andare avanti" mentre la regolamentazione si sta ancora concretizzando:

1. Classificazione di rischio del sistema, non del modello. La maggior parte dei team classifica il rischio dell'LLM. Ciò che il regolatore vuole classificare è il sistema sociotecnico completo: modello + retrieval + strumenti + flusso umano + dati. Senza quella mappa, non puoi nemmeno iniziare a rispondere all'Articolo 9 dell'AI Act.
2. Versionamento congiunto di modello, prompt e indice di retrieval. Un cambio in uno qualsiasi dei tre deve produrre un artifact immutabile, firmato e tracciabile. Se versioni il modello ma non l'indice di retrieval, non puoi riprodurre una decisione di sei mesi fa sotto una citazione giudiziaria. Non è più una preferenza di ingegneria, è un requisito.
3. Politiche di isolamento dati applicate all'output del retrieval, non solo all'input. La maggior parte delle fughe che vedo nei pilot regolamentati viene dal retrieval che recupera più del dovuto e dal modello che lo recita con sicurezza. La politica si applica prima che il contesto arrivi al modello, non dopo.
4. Gate di deployment con prova. Il push di un nuovo prompt in produzione dovrebbe passare una batteria minima di eval automatiche — allineamento, bias, fughe, comportamento degli strumenti — prima di toccare traffico reale. L'idea di proof-carrying deployment smette di essere accademica nel momento in cui il supervisore ti chiede l'evidenza di cosa hai validato prima del cambio.
5. Piano di ritiro controllato. Ogni agente in produzione dovrebbe avere un kill switch documentato, testato e di esecuzione misurata in minuti. Non "lo possiamo dismettere al prossimo sprint". Minuti. In un ambiente regolamentato, l'opzione di non agire è spesso più sicura che agire; il tuo sistema deve saperlo fare.

Nessuna di queste cinque cose viene gratis con nessuna piattaforma agentica vista sul mercato quest'anno. Tutte cinque sono lavoro di architettura proprio. McKinsey le vende come architettura di governance verificabile; io preferisco chiamarle runbook che un avvocato può firmare.

Il bias del rapporto: ottimista per costruzione

Un avvertimento sui dati. L'indagine McKinsey è risposta, per definizione, da profili che hanno già responsabilità diretta o competenza in governance, gestione del rischio o decisioni di investimento in IA. È un campione auto-selezionato verso le aziende che hanno quelle funzioni definite. La realtà nel mid-market è peggiore di quella riportata dal rapporto — non perché McKinsey inganni, ma perché le aziende senza un AI risk officer non rispondono a questo tipo di indagini e quindi non compaiono né al numeratore né al denominatore.

Se la tua organizzazione non ha qualcuno responsabile di rispondere a questa indagine, il tuo livello di maturità reale probabilmente non è 2,3. È più vicino a 1, e il primo compito non è salire a 3; è costruire il ruolo che permette di misurarlo con onestà.

Cosa metterei sulla mia roadmap questo trimestre

Se devo tradurre il rapporto in azioni concrete per un team di piattaforma in un settore regolamentato, farei questo prima del prossimo board update:

1. Inventario reale degli agenti in produzione, non solo quelli che il marketing chiama agenti. Contando cron job, webhook e script che chiamano un LLM con permessi elevati.
2. Una sola tabella che risponda a chi può fare cosa: agente, strumenti, scope, dati accessibili, umano responsabile, metriche di comportamento. Se non ci sta in una tabella, non la puoi difendere.
3. Budget esplicito di governance: persone, strumenti, eval, piattaforma. Il rapporto dice che chi investe oltre 25 M$ vede ritorno. La tua cifra non sarà quella, ma il principio sì: la governance senza budget è teatro.
4. Un esercizio di kill switch per ogni agente critico, cronometrato. Se ci mette più di dieci minuti, non ce l'hai.
5. Una conversazione adulta con rischio e compliance. La maturità di governance cresce quando ingegneria, rischio e compliance condividono il vocabolario. Il rapporto identifica correttamente quella brecha come barriera primaria per molte aziende; il rimedio è culturale e organizzativo prima che tecnico.

La linea che traccio

L'indagine McKinsey ha ragione sull'osservazione centrale: l'IA agentica sposta il problema da dire a fare, e questo cambia il tipo di governance che bisogna avere montata per mettere qualunque cosa in produzione. La mia domanda non è se il settore globale è più maturo (sì, un po') o se il rischio sale (chiaramente). La mia domanda è se, nel tuo sistema concreto, un esaminatore potrebbe chiedere il log delle azioni, il lineage della decisione, lo storico di validazione umana e il risultato dell'ultima eval prima del deployment — e tu potresti mettere tutti e quattro gli artefatti sul tavolo entro la stessa ora.

Se la risposta è sì, sei nel 33% con maturità reale e puoi iniziare a parlare di valore di business. Se la risposta è no, il 2,3 medio del rapporto resta aspirazionale per te, indipendentemente da cosa dica la slide del comitato.

Le aziende che vinceranno l'era agentica non saranno quelle che scalano agenti più velocemente. Saranno quelle che, quando il regolatore, l'auditor o l'investigatore di incidenti si presenteranno, potranno aprire il runbook e voltare pagina senza distogliere lo sguardo.

---

Fonti:

• McKinsey & Company, State of AI trust in 2026: Shifting to the agentic era, aprile 2026. mckinsey.com
• McKinsey & Company, Trust in the age of agents — Agentic AI governance for autonomous systems. mckinsey.com
• McKinsey & Company, Deploying agentic AI with safety and security: A playbook for technology leaders. mckinsey.com

Stai mettendo agenti IA in produzione sotto un regolatore reale e non sei sicuro che il tuo runbook regga il primo audit? Parla con un CTO — ti aiutiamo a separare la maturità reale dalla slide.