L’adozione dell’IA è una metrica di vanità

Chris Garrett è il vicepresidente della tecnologia gestita e delle operazioni di sicurezza presso Novatech, un fornitore di servizi gestiti. È anche l'autore di Scalare o vendere.

Abbiamo parlato con Chris per conoscere i suoi flussi di lavoro basati sull'AI e per capire come l'AI stia influenzando il settore. Ecco cosa ci ha raccontato.

Tradurre i sistemi in denaro

Gestisco i servizi IT e la sicurezza presso Novatech, un fornitore di servizi gestiti di proprietà di Perpetual Capital Partners. Il titolo dice vicepresidente. Il lavoro dice qualcosa di più semplice. Sono responsabile del fatto che la tecnologia faccia guadagnare denaro all'azienda o lo prosciughi silenziosamente.

Il percorso per arrivare fin qui non è stato lineare. Ho iniziato dal livello operativo, il luogo in cui i sistemi si guastano e qualcuno deve farsi carico della soluzione. Ho lavorato al supporto tecnico, poi nell'infrastruttura e infine nella sicurezza. Sono questi gli ambienti in cui il divario tra ciò che promette un fornitore e ciò che fa una rete diventa un problema tuo alle due del mattino. Quelle basi mi hanno insegnato una lezione che vale ancora oggi. La tecnologia non è il fine. Il risultato è proteggere i ricavi, valutare correttamente i rischi ed eliminare i tempi di inattività prima che il cliente se ne accorga.

Poi ho imparato a tradurre. Gli ingegneri parlano di sistemi e i dirigenti parlano di denaro, e la maggior parte dei responsabili tecnologici sceglie una lingua e perde l'altro pubblico. Ho costruito la mia carriera rimanendo in quella zona di confine, trasformando latenza, esposizione e architettura nel linguaggio dei margini e della continuità: l'IT come moltiplicatore, mai come centro di costo. Questa prospettiva ha cambiato le conversazioni a cui partecipavo e le decisioni che contribuivo a definire.

Ora il terreno si sta muovendo di nuovo. L'AI non è il prossimo strumento dello stack. Cambia il significato della leva, chi la detiene e la velocità con cui le capacità si accumulano. La maggior parte delle organizzazioni risponde con il rumore. Avviano progetti pilota che non dimostrano nulla e scrivono policy per gestire l'ansia anziché il rischio, mentre i fornitori vendono l'inevitabilità a compratori che non hanno fatto i conti.

Il mio interesse è più circoscritto e più difficile da simulare. Dove sposta davvero i numeri l'AI? Che cosa espone di già fragile? Quali competenze richiede che la maggior parte dei team ancora non possiede? La affronto come tutto il resto: prove invece di clamore, risultati invece di consenso, il livello dei sistemi invece della narrazione superficiale.

Le complessità del lavoro

Novatech è un fornitore di servizi gestiti di proprietà di Perpetual Capital Partners dal settembre 2024. Siamo un'azienda di servizi redditizia, post-acquisizione, con il mandato di aumentare i margini e i ricavi derivanti dalla sicurezza, mantenendo al contempo la qualità dell'erogazione che ci ha permesso di conquistare la nostra base clienti.

La divisione opera insieme ai servizi di tecnologia gestita, ufficio gestito e interventi sul campo, svolgendo il lavoro necessario a mantenere operative e protette le attività dei clienti. Il mio team è composto da 68 ingegneri e analisti distribuiti tra assistenza tecnica, infrastruttura e una divisione dedicata alla sicurezza, a supporto di 400 ambienti cliente.

L'architettura non è un singolo prodotto; è condivisa tra più clienti. Gestiamo decine di ambienti cliente distinti, ciascuno con una combinazione propria di infrastrutture in sede, Microsoft 365, Azure, AWS e Google Cloud, oltre a reti ibride che non abbiamo sempre progettato noi, ma di cui ora siamo responsabili. Questa variabilità crea complessità. Una modifica ordinaria per un cliente rappresenta un rischio per la produzione di un altro. La disciplina consiste nel gestire questa flotta secondo un unico standard di affidabilità e livello di sicurezza, senza costringere ogni cliente nello stesso modello.

Il nostro modello di implementazione è gestito e basato innanzitutto sull'accesso remoto, con il supporto degli interventi sul campo per le attività che richiedono una presenza in loco. Monitoriamo, applichiamo aggiornamenti correttivi e proteggiamo continuamente. Misuriamo le nostre prestazioni in base al tempo di attività, ai tempi di risposta e alla rapidità con cui conteniamo gli eventi di sicurezza prima che i clienti ne subiscano le conseguenze.

Come l'AI trasforma i processi decisionali tecnici, ma non li controlla

La mia filosofia di base è "Avvolgere l'ingegnere nell'AI" per ottenere il meglio da entrambi i mondi. Nessuna riduzione del personale; al contrario, il team svolge una quantità maggiore di lavoro e lo fa meglio grazie a strumenti di assistenza.

Oggi l'AI alimenta le attività ad alto volume in cui un revisore umano è sempre stato il collo di bottiglia, senza però rappresentare il valore aggiunto. Per esempio, la classificazione iniziale degli avvisi di sicurezza passa innanzitutto attraverso un livello di AI, perché un analista SOC che legge manualmente diecimila eventi a basso segnale è costoso e ottiene prestazioni peggiori rispetto al modello.

Utilizziamo l'AI in modo analogo per l'analisi dei registri durante le indagini, per la prima stesura della documentazione e delle procedure operative e per riassumere l'ambiente di un cliente prima di una verifica. In questo modo l'ingegnere arriva preparato anziché alla cieca. In tutti questi casi, l'AI accelera la lettura; non prende la decisione.

La decisione resta umana, e il confine è intenzionale. Le decisioni architetturali relative all'ambiente di un cliente restano umane perché il modello ottimizza la risposta tecnicamente più pulita. Una decisione reale tiene conto del budget, della tolleranza al rischio del cliente e di ciò che il suo team è effettivamente in grado di gestire dopo la nostra partenza.

La risposta agli incidenti rimane affidata alle persone a livello decisionale. L'IA può far emergere ciò che è accaduto, ma le scelte di contenimento comportano conseguenze aziendali, esposizione legale e fiducia dei clienti. Non affiderò il giudizio sotto pressione a uno strumento che non può essere ritenuto responsabile dell'esito. Anche la revisione finale della sicurezza prima dell'approvazione rimane affidata alle persone per lo stesso motivo. Il modello eccelle nell'individuare schemi noti, ma è cieco di fronte ai problemi nuovi che contano davvero.

Un flusso di lavoro reale per la classificazione degli avvisi di sicurezza

Esaminiamo più a fondo la classificazione degli avvisi di sicurezza, perché viene eseguita quotidianamente e mostra chiaramente dove l'IA è efficace e dove subentra una persona.

Il processo inizia con un volume che nessuna persona può o dovrebbe elaborare manualmente con regolarità. Nell'intero parco clienti, il nostro sistema di monitoraggio genera decine di migliaia di eventi ogni giorno, la maggior parte dei quali è rumore. Prima dell'IA, un analista gestiva una coda e il segnale reale rimaneva sepolto sotto tentativi di accesso falliti e anomalie innocue. I problemi importanti ricevevano attenzione in ritardo perché l'analista doveva farsi strada attraverso il rumore per trovarli.

Il livello di IA elabora innanzitutto quel flusso grezzo. Raggruppa gli eventi correlati, elimina i falsi positivi evidenti confrontandoli con schemi noti e affidabili, mette in relazione le attività all'interno di un ambiente cliente che una persona considererebbe privo di connessioni e assegna una priorità agli elementi rimanenti in base alla loro somiglianza con un'intrusione reale. L'analista non riceve un flusso ininterrotto di dati. Riceve invece un breve elenco ordinato, corredato dal contesto, dai nomi dei sistemi interessati e da una spiegazione esplicita del motivo per cui ciascun elemento è stato segnalato. Il modello esegue la lettura iniziale, ma non prende decisioni.

L'analista apre quell'elenco e inizia il lavoro umano. Esamina il filo sospetto e l'IA fornisce nuovamente assistenza, riassumendo i registri pertinenti e la cronologia, consentendo all'analista di ricostruire gli eventi in pochi minuti invece che in un'ora. Il giudizio rimane affidato alla persona. Si tratta di una compromissione reale o di una modifica autorizzata che appare sospetta? Lo schema corrisponde a qualcosa di nuovo che il modello non segnalerebbe? Il modello accelera la revisione delle prove; l'analista prende la decisione.

Quando si verifica un evento reale, il contenimento rimane una decisione di comando affidata a una persona. L'analista, o il responsabile senior di reperibilità per gli incidenti gravi, decide se isolare un host, disabilitare un account o scollegare un cliente. Queste scelte comportano costi aziendali, esposizione legale e fiducia dei clienti, e nessuno strumento può essere ritenuto responsabile di tali decisioni. L'IA può dirti che cosa è accaduto, ma non sceglie la nostra risposta sotto pressione.

Dopo il contenimento, l'IA redige la registrazione dell'incidente, la cronologia, le azioni intraprese e il riepilogo destinato al cliente. Questa bozza fa risparmiare molto tempo rispetto al partire da una pagina vuota. Non viene inviata finché un ingegnere non la corregge e non la firma. Un rapporto errato ma ben confezionato è peggiore di nessun rapporto, e una procedura ufficiale redatta dall'IA senza un responsabile umano crea una responsabilità che abbiamo deciso non si sarebbe mai verificata sotto la nostra supervisione.

Il ciclo si conclude con un passaggio che la maggior parte dei team salta. Campioniamo ciò che l'IA ha scartato, non solo ciò che ha inoltrato, e reinseriamo questi errori nel processo per perfezionare il passaggio successivo. Questa disciplina di campionamento impedisce che si instauri un'eccessiva fiducia nell'automazione. Uno strumento che rende gli analisti più veloci li rende anche compiacenti se nessuno controlla gli elementi che scarta.

Perché le aziende devono ripulire le autorizzazioni prima di integrare l'IA

Ho inoltre implementato un controllo di governance su Microsoft Copilot.

In precedenza, Copilot sembrava un miglioramento della produttività e i clienti lo consideravano un semplice interruttore da attivare. Il problema è che Copilot eredita gli accessi già esistenti di un utente. La maggior parte dei nostri clienti aveva accumulato negli anni una proliferazione delle autorizzazioni: siti SharePoint aperti, unità condivise che nessuno aveva ripulito e file tecnicamente accessibili ma praticamente invisibili. Nel momento in cui dai a un dipendente uno strumento che cerca in tutto ciò a cui può accedere, i contenuti invisibili diventano risultati di ricerca. Un dipendente junior avrebbe potuto porre una domanda in linguaggio naturale e far emergere dati sugli stipendi o una presentazione del consiglio di amministrazione che non era mai stata destinata a lui. Nessuno aveva affrontato il problema delle autorizzazioni, ma l'esposizione era reale e rimaneva lì da anni.

Ho creato una valutazione obbligatoria della preparazione che viene eseguita prima di abilitare Copilot per chiunque. Mappiamo gli accessi effettivi, individuiamo i contenuti condivisi eccessivamente e correggiamo prima il modello delle autorizzazioni. Il cliente approva ciò a cui le proprie persone possono accedere prima che venga attivata una sola licenza di IA. Abbiamo trasformato una richiesta di funzionalità in un'implementazione governata con un prerequisito vincolante.

Chris sottolinea

Nel momento in cui dai a un dipendente uno strumento che cerca tutto ciò a cui può accedere, i contenuti invisibili diventano risultati di ricerca.

Come i vantaggi dell'IA comportano costi in termini di disciplina

Dal punto di vista della sicurezza, il livello di selezione degli avvisi ha ridotto di circa il 70 percento il volume che gli analisti devono gestire manualmente. Il tempo medio per riconoscere un avviso reale è passato da ore a minuti durante le fasce di minore attività, perché gli analisti non devono più setacciare il rumore per trovare gli eventi importanti. Questa è la nostra vittoria più netta. Il costo di sbagliare è basso; un essere umano controlla comunque l'elenco ristretto e il modello eccelle nel riconoscimento dei modelli, un'attività in cui gli esseri umani hanno difficoltà giorno dopo giorno.

Il lavoro sulla preparazione a CoPilot ha prodotto un risultato di tipo diverso. Abbiamo trovato dati esposti in ogni valutazione che abbiamo eseguito, problemi precedenti all'IA che sarebbero rimasti sepolti. Questa è buona sicurezza e buon fatturato.

I vantaggi nella stesura sono reali, ma inferiori a quanto sostiene l'entusiasmo generale. La documentazione e le bozze dei manuali operativi assistite dall'IA hanno ridotto di oltre la metà il tempo necessario per una prima versione. Un ingegnere deve comunque correggere il lavoro, quindi il risparmio riguarda il problema della pagina bianca, non il prodotto finale.

La modalità di errore che ci è costata di più è stata il pregiudizio verso l'automazione. All'inizio, un paio di analisti hanno iniziato a fidarsi troppo della selezione degli avvisi dell'IA e hanno lasciato passare casi che avrebbero dovuto aprire. Lo abbiamo rilevato durante la revisione, ma ho imparato che uno strumento che rende le persone più veloci le rende anche più pigre se glielo si permette, e la soluzione è stata il processo, non la tecnologia. Ora campioniamo ciò che l'IA scarta, non solo ciò che porta alla nostra attenzione.

In breve, l'IA ci ha fatto guadagnare velocità ovunque, ma non capacità di giudizio. Ogni vantaggio comportava un costo in termini di disciplina per impedire alle persone di fidarsi dello strumento oltre quanto meritasse.

Come l'IA migliora la produzione, ma non le capacità

Ecco qualcosa di cui nessuno vuole parlare: l'IA non ha reso le persone più capaci. Ha permesso loro di prendere in prestito l'apparenza della capacità e fingere che fosse quella reale.

Chiamiamolo "prendere in prestito una voce". Una persona produce un artefatto che non avrebbe potuto produrre da sola — per esempio codice, una motivazione architetturale, una politica di sicurezza o un'analisi destinata al cliente — e l'artefatto appare fluido e autorevole. La fluidità è reale. Le parole prendono in prestito la competenza sottostante, che scompare nel momento in cui il modello smette di digitare. La persona possiede il risultato, ma non la comprensione. Questa lacuna è invisibile finché qualcosa non si rompe, e allora diventa la cosa più evidente nella stanza.

Ecco un esempio: un ingegnere junior rilascia una correzione generata dall'IA che funziona nella dimostrazione, poi tre settimane dopo non riesce a spiegarla durante un incidente. Così, un ingegnere senior ricostruisce una soluzione che nessuno del team ha progettato. La velocità ottenuta all'inizio ha portato a un costo successivo, e il costo è stato maggiore perché la superficie fluida ha ritardato il momento in cui qualcuno ha verificato la sostanza.

L'aspettativa disattesa era la leva. La promessa era che l'IA avrebbe moltiplicato le persone competenti. Ciò che fa è appiattire la differenza visibile tra chi sa e chi sa soltanto impartire comandi, e questo appiattimento è costoso perché i due producono un lavoro dall'aspetto identico e risultati completamente diversi sotto carico.

L'unico uso duraturo dell'IA, quindi, si verifica quando qualcuno che possiede già la competenza usa l'IA per lavorare più velocemente, perché quella persona sa riconoscere quando il risultato è sbagliato. Affidare lo stesso strumento a qualcuno che prende semplicemente in prestito la competenza non aggiunge capacità. Aggiunge un risultato sicuro di sé senza nessuno che ne sia responsabile.

Perché i collaboratori junior sono ancora necessari con l'IA

Chris sottolinea

Un modo per evitare di arrivare a quel punto consiste nell’implementare l’IA in modo più circoscritto, ottenendo l’accesso un livello alla volta. Gli stessi vantaggi senza definanziare silenziosamente il percorso che forma i senior che rendono tutto questo sicuro.

Questo è il modello che ho usato per costruire ogni organizzazione di servizi che abbia mai gestito: collocare la capacità junior sotto la supervisione senior, lasciare che il volume di lavoro scenda fino alle risorse competenti meno costose e far crescere la piramide con l'aumentare della domanda.

L'IA ha eliminato la base della piramide. Il lavoro che prima affidavo ai junior — selezione iniziale degli avvisi, lettura dei registri, stesura dei manuali operativi, ticket di routine — è esattamente il lavoro che ora il modello svolge più velocemente e a un costo inferiore rispetto a una persona che sta imparando sul campo. La logica dell'organico che dipendeva da un'ampia base di lavoro voluminoso a basso costo non regge più, perché il lavoro voluminoso non ha più bisogno di una persona.

Ma il livello junior non è mai stato solo manodopera a basso costo. Era il campo di addestramento. Le persone sono diventate i senior su cui faccio affidamento affrontando migliaia di ticket a basso rischio e sviluppando capacità di giudizio, un errore alla volta. Eliminare quel gradino non significa soltanto cambiare la struttura dei costi di quest'anno. Significa smettere di formare gli ingegneri senior di cui avrete bisogno tra cinque anni, e non sentirete quella mancanza finché non sarà costoso colmarla.

Un modo per evitare di arrivare a quel punto consiste nell'introdurre l'IA in modo più circoscritto, conquistando ogni livello uno alla volta. Gli stessi vantaggi, senza depauperare silenziosamente il bacino da cui provengono i senior che rendono tutto questo sicuro.

Io non l'ho fatto, quindi sto ricostruendo la scala. Manteniamo i junior, ma non per assorbire un volume che il modello gestisce già. Sono lì per sviluppare l'unica cosa che l'IA non può offrire loro: la capacità di giudizio necessaria per capire quando il suo risultato sicuro di sé è sbagliato. Questo significa esporli deliberatamente ai problemi difficili fin dall'inizio, dedicare il tempo dei senior all'insegnamento invece che alla delega e costruire una base più ridotta e più preparata di quella che la vecchia logica economica avrebbe creato.

Perché l'adozione è una metrica di vanità

Il lancio fallisce a livello umano, non a livello tecnologico. Ho dovuto fare marcia indietro quasi su tutto perché avevo invertito l'ordine delle cose.

Ho trattato il lancio come un problema di capacità. Scegliere gli strumenti, dimostrare che funzionano, dare alle persone l'accesso, misurare l'adozione. L'adozione è aumentata e l'ho interpretata come un successo. In realtà stavo osservando persone che si sentivano a proprio agio nel fidarsi di risultati che non avevano imparato a mettere in discussione, e questa sicurezza è un sintomo precoce del fallimento, non una prova di successo.

A proposito, avrei dovuto rifiutarmi di misurare l'adozione. È un numero di vanità e mi ha indicato la direzione sbagliata. La metrica importante era verificare se le persone controllavano il risultato prima di fidarsene, ma questo è più difficile da conteggiare, quindi ho monitorato invece la cosa più facile. Misurare l'utilizzo premiava esattamente il comportamento che aveva causato il caos: le persone si affidavano di più allo strumento, più velocemente e con meno attenzione.

Ora misurerei le verifiche e il lavoro da rifare, e non permetterei mai più che un grafico sull'utilizzo prendesse il posto di un miglioramento effettivo del lavoro.

Perché i CTO devono collegare ogni decisione sull'IA ai numeri dell'azienda

Ecco i miei consigli:

1. Prima di tutto, la governance. Non è entusiasmante e non farà presa sul pubblico FOMO come gli ultimi modelli all'avanguardia, ma è assolutamente necessaria. Governate l'intera superficie prima di implementarla e ampliarla. La maggior parte dei problemi seri che ho visto è nata da CTO che hanno implementato l'IA per aumentare la velocità e hanno scritto le regole di governance in un secondo momento. Invertite quest'ordine.
2. Smettete di acquistare maturità e iniziate ad acquistare capacità verificabile. Metà dell'IA presentata nelle proposte dei fornitori non fa altro che integrare un'API, venduta come competenza interna. Chiedete a ogni fornitore di mostrarvi il prodotto funzionante su un problema al di fuori della sua dimostrazione e chiedete ai vostri team di fare lo stesso.
3. Proteggete le persone che già sanno come fare. La leva è reale solo nelle mani di qualcuno in grado di capire quando il modello sbaglia. Investite in questa capacità di giudizio, misuratela e rifiutatevi di considerare la padronanza dei prompt come un suo sostituto nell'organigramma.
4. Collegate ogni decisione sull'IA a un numero a cui l'azienda tiene già. Proteggete i ricavi, valutate il rischio e restituite ore alle persone che svolgono lavori importanti. I CTO che presentano l'IA come un'iniziativa tecnologica dovranno lottare per il budget ogni trimestre. Quelli che la presentano in termini di margini e rischio saranno interpellati nelle riunioni in cui un tempo si prendevano decisioni senza di loro. L'argomentazione tecnica raramente convince un dirigente; lo fa la matematica di profitti e perdite.
5. Agite con disciplina. Implementate l'IA dove una persona mantiene comunque la responsabilità del risultato, tenetela lontana dal ruolo in cui il risultato non ammette errori e verificate ciò che scarta, non solo ciò che segnala. In questo momento il mercato premia la velocità e passerà i prossimi anni a rivalutare i team che hanno scambiato la padronanza dei termini per competenza. Costruite il vostro sistema in modo da non essere tra questi.

Seguiteci

Puoi seguire il lavoro di Chris Garrett su LinkedIn. E dai un'occhiata al suo ultimo libro, Scalare o vendere.

Presto arriveranno altre interviste a esperti su The CTO Club!