Mark Fetches, CTO di Spinnaker Support – Serie di interviste

Mark Fetches è Chief Technology Officer per l’EMEA di Spinnaker Support, dove consiglia le organizzazioni aziendali sulla strategia tecnologica, la sicurezza, il cloud, l’AI e le iniziative di trasformazione su larga scala. Con oltre 30 anni di esperienza nel consulting e nella leadership presso Accenture, Deloitte e PwC, Mark ha lavorato a stretto contatto con i dirigenti e i consigli di amministrazione per modernizzare ambienti aziendali complessi e allineare le decisioni tecnologiche con gli obiettivi aziendali a lungo termine. Con sede nel Regno Unito, si specializza nell’aiutare le organizzazioni a navigare le sfide della tecnologia legacy, il rischio operativo e la trasformazione digitale con una guida pratica e orientata agli affari.

Spinnaker Support è un fornitore leader a livello globale di supporto software di terze parti, servizi gestiti e consulenza sulla sicurezza per le aziende che utilizzano piattaforme critiche come Oracle (ORCL ), SAP, JD Edwards e altre.

Ha trascorso oltre 20 anni a consigliare le aziende presso Accenture, Deloitte e PwC prima di diventare CTO di Spinnaker Support. Guardando indietro a quel percorso, quali sono i più grandi malintesi che i dirigenti hanno avuto costantemente sul rischio tecnologico e come l’ascesa dell’AI ha cambiato quelle conversazioni?

Credo che il più grande malinteso sia sempre stato che il rischio tecnologico si trova da qualche parte ai margini dell’azienda e possa essere gestito come un problema specialistico. Non l’ho mai visto in questo modo.

La maggior parte dei rischi seri che ho visto deriva dalle scelte di leadership. Quanto complessità si tollera. Quanto si diventa dipendenti da piattaforme vecchie o da fornitori chiave. Quanto si spinge per la velocità. Se si confida realmente nei dati su cui l’azienda si basa. La tecnologia è dove queste scelte si manifestano, ma di solito non è dove iniziano.

Nel corso degli anni, ho visto molti dirigenti concentrarsi sulle cose ovvie come la sicurezza informatica, la conformità e la riduzione dei costi. Queste sono questioni reali, naturalmente. Ma i rischi che tendono a mettere in difficoltà le aziende sono spesso più silenziosi di così. È la piattaforma che tutti sanno essere fragile ma continuano a rinviare la sua sostituzione. È il problema dei dati che nessuno possiede veramente. È la dipendenza esternalizzata che sembra efficiente finché non diventa un collo di bottiglia. Queste sono le cose che possono stare in secondo piano per anni e poi diventare molto visibili quando qualcosa si rompe.

Credo anche che ci sia stata una lunga abitudine di confondere la conformità con la resilienza. Non sono la stessa cosa. Puoi superare un’audizione e ancora essere molto più esposto di quanto pensi. Una checklist non ti dice come l’azienda risponderà sotto pressione, quanto velocemente potrà riprendersi o se i leader stanno realmente vedendo il problema con sufficiente chiarezza per agire.

Cosa l’AI ha cambiato è il livello di attenzione. Queste conversazioni un tempo si tenevano più in basso nella organizzazione. Ora sono proprio al centro delle discussioni nella sala del consiglio di amministrazione su crescita, fiducia, produttività e marchio. Questo è un bene. Ma ha anche introdotto una nuova semplificazione, che è l’idea che il modello AI utilizzato sia il rischio. Di solito, è più grande di così. Le domande più difficili sono sui dati e sulla governance intorno ad esso, sulle decisioni che influenza e sul punto in cui il giudizio umano deve ancora contare.

Quindi, se dovessi riassumerlo, direi che il rischio tecnologico non è mai stato realmente sulla tecnologia da solo. È sempre stato una riflessione del giudizio di leadership. L’AI ha solo reso più difficile ignorarlo.

Le squadre di sicurezza ora hanno accesso a più informazioni sulle vulnerabilità di quanto mai prima, eppure le organizzazioni continuano a lottare con la priorità. Perché crede che l’industria abbia un problema di segnale-rumore piuttosto che un problema di rilevamento?

Lo spiegherei semplicemente: l’industria non è a corto di dati sulle vulnerabilità. È a corto di chiarezza.

La maggior parte delle squadre di sicurezza già hanno più input di quanti ne possano gestire, output degli scanner, intelligence sulle minacce, punteggi di gravità, consigli per le patch, reporting degli exploit. Il problema non è se possano trovare debolezze. È se possano separare quelle che potrebbero realmente danneggiare l’azienda da quelle che sono tecnicamente interessanti ma meno conseguenziali.

È per questo che lo vedo come un problema di segnale-rumore. Il rilevamento è migliorato enormemente. Cosa non ha tenuto il passo è la capacità di applicare il contesto. Una vulnerabilità diventa una vera priorità solo quando si capisce dove si trova, quanto è esposta, quanto critica è l’asset, quali controlli compensativi esistono e quale sarebbe l’impatto aziendale se venisse sfruttata.

Nella pratica, molte organizzazioni ancora ricadono nelle metriche più facili da produrre come punteggi di gravità, conti delle patch e rapporti di aging. Queste sono utili, ma non sono la stessa cosa del giudizio umano. Un problema ad alto punteggio in un sistema interno a basso valore può importare molto meno di un problema a punteggio più basso che si trova su qualcosa di front-end o criticamente operativo.

Quindi, non credo che questo sia fondamentalmente un problema di visibilità. È un problema di priorità aziendale che deve essere appreso dalle squadre di sicurezza. Siamo diventati molto bravi a generare risultati. Siamo ancora meno consistenti nel tradurre quei risultati in un elenco breve di azioni che la leadership possa sostenere con fiducia.

E dalla mia prospettiva, questo è il vero passo che l’industria deve ancora fare, un passo verso la misurazione di cosa realmente conta in termini di impatto aziendale.

Al livello del consiglio di amministrazione, questo è veramente una questione di traduzione del rischio, può l’organizzazione convertire l’esposizione tecnica in un numero limitato di priorità aziendali chiare e azionabili? Quelli che possono farlo bene sono quelli che si spostano dal rumore al segnale.

Molti vendor di sicurezza sostengono che l’AI può automaticamente priorizzare le vulnerabilità e prevedere le minacce. Dove vede la lacuna tra il racconto di marketing e cosa l’AI può realisticamente consegnare oggi negli ambienti aziendali?

Credo che il modo più semplice per dirlo sia che il marketing intorno a questo tende a promettere un livello di certezza che gli ambienti aziendali reali semplicemente non consentono.

I vendor spesso descrivono l’AI come se potesse elevarsi al di sopra del rumore, prendere tutto e dire in modo affidabile alla squadra di sicurezza cosa conta di più e cosa probabilmente accadrà dopo. È un pitch convincente perché ogni leader della sicurezza vuole meno confusione e più fiducia. Ma una volta che si entra in un’organizzazione di grandi dimensioni, le cose sono raramente così pulite da far sì che quella promessa si mantenga in modo così diretto.

L’AI può assolutamente aiutare. Può mettere insieme pattern, ridurre un po’ della sorta manuale e aiutare le squadre a lavorare attraverso volumi di informazioni che altrimenti sarebbero difficili da gestire, e questo ha un valore reale. Ma c’è una differenza tra aiutare una squadra a muoversi più velocemente e sapere con precisione affidabile cosa debba essere più importante in quell’ambiente specifico.

Quella è la lacuna. La maggior parte delle aziende è piena di contesti disomogenei. Gli inventari degli asset sono incompleti. La proprietà non è sempre chiara. La criticità aziendale cambia. I controlli variano da una parte dell’estate all’altra. La qualità dei dati è mista. Se l’immagine sottostante è patchy, allora l’output dell’AI sarà patchy anche lui, per quanto l’interfaccia possa sembrare lucida.

Credo che questo sia particolarmente vero quando i vendor parlano di previsione. C’è una differenza significativa tra dire “questo pattern sembra rischioso” e dire “questo è ciò che accadrà dopo”. Il primo può essere utile. Il secondo è dove il linguaggio spesso supera la realtà.

Quindi, per me, l’AI è meglio intesa oggi come un amplificatore, non come un’autorità. Può aiutare le squadre a selezionare, correlare e focalizzarsi. Cosa non può fare in modo consistente è sostituire il bisogno di giudizio umano, conoscenza locale e una chiara comprensione di cosa l’azienda si cura veramente.

Quella è la divisione. Il racconto suggerisce certezza. La realtà è più modesta e più utile della hype se si è onesti al riguardo. L’AI può migliorare la qualità e la velocità dell’analisi, ma non rimuove la complessità della presa di decisioni sulla sicurezza aziendale.

Spinnaker Support lavora estensivamente con implementazioni Oracle, SAP e JD Edwards. Cosa rende gli ambienti ERP altamente personalizzati particolarmente difficili per gli strumenti di sicurezza guidati dall’AI da comprendere e valutare con precisione?

Cosa li rende difficili è che, dopo abbastanza anni, smettono di comportarsi come software standard su cui l’AI è stata addestrata e iniziano a comportarsi più come un registro di come l’azienda funziona veramente.

Ho visto che questo è particolarmente vero negli stati patrimoniali Oracle, SAP e JD Edwards altamente personalizzati. Sulla carta, potresti ancora guardare una piattaforma nota. Nella realtà, spesso guardi anni di adattamenti locali, codice personalizzato, integrazioni ereditate, strutture di permesso, logica di reporting e soluzioni create per ragioni operative molto specifiche. Per uno strumento di sicurezza guidato dall’AI, credo che questo possa essere difficile da leggere con qualsiasi reale fiducia.

Molti di questi strumenti funzionano meglio quando l’ambiente è relativamente coerente e i pattern sono più facili da confrontare. Gli ambienti ERP altamente personalizzati raramente sono così. La logica è più intricata. La documentazione è spesso incompleta. La proprietà può essere diffusa tra i team. Cosa sembra insolito può essere perfettamente intenzionale e cosa sembra routine può rivelarsi supportare qualcosa di genuinamente critico in finanza, catena di approvvigionamento o operazioni.

Questo è dove si trova la difficoltà. Lo strumento non è solo chiamato a individuare una vulnerabilità o una cattiva configurazione. È chiamato a capire cosa significa quel problema nel contesto di un processo aziendale, una dipendenza personalizzata o una struttura di controllo che potrebbe non esistere da nessun’altra parte.

E questo è un problema molto più difficile di quanto il marketing spesso implichi. L’AI può aiutare a mettere in evidenza i pattern, ridurre un po’ dell’analisi manuale e aiutare le squadre a lavorare attraverso volumi di informazioni che altrimenti sarebbero difficili da gestire, e questo ha un valore reale. Ma se lo stato patrimoniale è solo parzialmente documentato, plasmato da anni di eccezioni e profondamente legato al modo in cui l’azienda opera, c’è un limite a quanto precisamente un sistema automatizzato possa interpretarlo da solo.

Quindi, credo che il vero problema non sia se l’AI possa vedere qualcosa. È se possa capire abbastanza del contesto circostante per giudicarlo correttamente. Negli ambienti ERP altamente personalizzati, questo è ancora dove l’esperienza umana fa la differenza.

Una delle sue argomentazioni chiave è che l’esperienza umana non è un collo di bottiglia da eliminare, ma una parte essenziale del processo di sicurezza. Può condividere esempi in cui il giudizio umano ha identificato rischi che un motore di priorità guidato dall’AI avrebbe probabilmente perso?

Sì, assolutamente. E per me, questo è dove i limiti della priorità automatizzata diventano molto ovvi.

Alcuni rischi hanno senso solo una volta che si conosce l’ambiente abbastanza da capire cosa si trova dietro i dati. Un sistema può non sembrare particolarmente importante dall’esterno. Il punteggio della vulnerabilità può essere insignificante. Ma qualcuno che conosce lo stato patrimoniale può sapere che supporta la retribuzione, il reporting di fine trimestre, un’integrazione fragile o un processo aziendale che l’azienda semplicemente non può permettersi di interrompere. Il segnale nei dati può sembrare ordinario. La conseguenza nel mondo reale non lo è.

Ho anche visto casi in cui l’immagine dei controlli sembra migliore in teoria di quanto non sia in pratica. Un motore AI potrebbe supporre che un rischio è ridotto perché la segmentazione è in atto, o perché l’accesso è limitato o perché esiste un controllo di monitoraggio. Ma una persona vicina all’ambiente può sapere che un controllo è applicato in modo inconsistente, un altro è bypassato quando le operazioni sono sotto pressione e un terzo ha smesso di essere affidabile. Quel tipo di lacuna non sempre si presenta in modo chiaro nel sistema di registrazione.

La stessa cosa accade negli ambienti personalizzati. Uno script, un flusso di lavoro o un modello di permesso può sembrare routine se si sta scansionando per pattern su larga scala. Per qualcuno che capisce come quel sistema sia stato adattato nel tempo, lo stesso dettaglio può spiccare immediatamente come una vera fonte di esposizione.

Il timing conta anche. Una vulnerabilità può sembrare gestibile in isolamento, poi diventare molto più seria perché l’azienda è in mezzo a una migrazione, un’acquisizione, una scadenza normativa o un periodo operativo di picco. Quel tipo di spostamento non è sempre facile per un motore automatizzato da interpretare con il giusto peso.

Quindi, quando parlo di esperienza umana, non sto parlando di istinto in qualche senso vago. Sto parlando di conoscenza locale. Memoria. Giudizio. La capacità di vedere quando un piccolo problema tecnico è attaccato a qualcosa di molto più conseguenziale.

Quella è la ragione per cui non vedo l’esperienza umana come un collo di bottiglia da rimuovere. La vedo come la parte che impedisce la falsa fiducia. L’AI può aiutare a selezionare e restringere i dati. Ma i rischi che contano di più sono spesso quelli che diventano ovvi solo quando qualcuno capisce come funziona veramente l’azienda.

Mentre le organizzazioni si affrettano ad adottare l’AI attraverso le operazioni di sicurezza, quali sono i più grandi rischi dell’automatizzazione eccessiva della gestione delle vulnerabilità e della valutazione dell’esposizione?

Il più grande rischio che vedo è che si crei l’apparenza di controllo senza la realtà di capire veramente di essere in controllo.

La gestione delle vulnerabilità è una di quelle aree in cui l’automazione è ovviamente preziosa. A livello aziendale, hai bisogno dell’automazione per trovare problemi, correlare dati, priorizzare in massa e tenere in movimento l’intero processo. Nessuna organizzazione seria può gestire questo manualmente.

Ma il pericolo arriva quando l’automazione inizia a guidare il programma senza sufficiente sfida umana intorno ad esso.

Il primo rischio ovvio è la falsa priorità. Se si fa affidamento troppo pesantemente sulla valutazione automatizzata, si può finire per trattare la gravità tecnica come se fosse la stessa cosa del rischio aziendale. Non lo è. Una vulnerabilità critica su un asset isolato o compensato può importare meno nella pratica di un problema a punteggio più basso che si trova su un sistema altamente esposto legato a un processo aziendale critico.

Il secondo rischio che vedo è la perdita di contesto. I programmi automatizzati sono solo buoni quanto i dati sugli asset, i dati sulla proprietà, la mappatura delle dipendenze e la gestione delle eccezioni dietro di essi. Se quelle informazioni sono incomplete, e nella maggior parte delle aziende alcune di esse lo sono, allora l’automazione può diventare molto efficiente nel muovere decisioni difettose attraverso il sistema.

Il terzo rischio è comportamentale. Una volta che le persone iniziano a fidarsi troppo del flusso di lavoro, smettono di interrogare i suoi output. Le squadre assumono che ciò che emerge in cima debba essere ciò che conta di più e ciò che non emerge può aspettare. Questo è comprensibile, ma credo pericoloso. Perché sposta la cultura dal gestire il rischio in modo informato all’accettazione passiva dell’ordinamento guidato dalla macchina.

E poi c’è un rischio strategico più ampio, che è che le organizzazioni inizino a confondere il throughput con il miglioramento della sicurezza. Chiudere un alto volume di vulnerabilità sembra buono operativamente. Crea dashboard, metriche e una sensazione di slancio. Ma se non si sta riducendo le esposizioni che contano di più per l’azienda, si potrebbe semplicemente diventare più veloci nel sembrare impegnati.

Quindi, la mia opinione è che l’automazione dovrebbe assolutamente fare il lavoro pesante. Ma dovrebbe supportare il giudizio, non sostituirlo. Altrimenti, si finisce con un processo che è efficiente, misurabile e scalabile, ma non necessariamente più sicuro.

Ha lavorato estensivamente nella trasformazione IT e nell’architettura aziendale. Come dovrebbero i CISO bilanciare la necessità di patchare le vulnerabilità rapidamente contro i rischi operativi di interrompere sistemi aziendali mission-critici?

Ottima domanda, poiché questo è uno di quei settori in cui la risposta facile è solitamente quella sbagliata.

Certo che si vuole patchare rapidamente. Nessun CISO sosterrà mai sedersi su vulnerabilità note più a lungo del necessario. Ma in un’azienda reale, specialmente quella che esegue sistemi critici, la velocità da sola non è l’obiettivo. Se si patcha male e si prende qualcosa di cui l’azienda si fida, si risolve un problema creandone un altro.

Quindi, l’equilibrio è veramente capire quali rischi sono vivi, quali sono teorici e quali sistemi possono tollerare il cambiamento senza causare problemi da qualche altra parte.

Alcune vulnerabilità richiedono veramente azione urgente. Se qualcosa è esposto, sfruttabile e si trova in una parte dello stato patrimoniale che conta, allora si agisce. Ma la maggior parte delle volte, la decisione è meno assoluta di quanto la gente faccia sembrare. Potresti avere altri controlli intorno al problema. Il sistema interessato potrebbe essere strettamente contenuto. Il rischio operativo di apportare il cambiamento oggi potrebbe essere più alto del mantenerlo per un breve periodo e farlo correttamente.

Questo è il motivo per cui i migliori CISO tendono ad essere quelli che possono avere una conversazione adulta con l’azienda. Non solo “Questo è critico, patchalo adesso”, ma “Ecco l’esposizione, ecco cosa potrebbe accadere, ecco cosa potrebbe andare storto se interveniamo male e questo è il modo più sicuro per farlo”. Questo è un tipo più credibile di leadership che non trattare ogni vulnerabilità come se esistesse in isolamento.

Credo anche che questi momenti espongano qualcosa di più profondo sullo stato patrimoniale stesso. Se un’organizzazione ha paura costantemente di patchare i sistemi core perché ogni cambiamento sembra pericoloso, questo di solito ti dice che l’ambiente è diventato fragile. Troppa dipendenza nascosta, non abbastanza fiducia nei test, troppa poca resilienza nell’architettura. In quella situazione, il dibattito sulle patch è veramente un sintomo di un problema molto più vecchio.

Quindi, sì, patcha rapidamente dove il rischio è reale e il percorso è chiaro. Ma dove l’ambiente è sensibile, il lavoro è ridurre il rischio senza creare un pasticcio più grande. Questo è l’equilibrio.

E per essere onesto, la maggior parte dei CISO esperti già lo sa. La sfida è applicare la loro decisione sotto pressione, quando il tempo stringe e nessuno vuole possedere le conseguenze di sbagliare.

L’approccio di Spinnaker combina l’analisi guidata dall’AI con la convalida degli esperti. Quali compiti dovrebbero gestire l’AI e quali decisioni dovrebbero rimanere saldamente in mano agli esperti di sicurezza esperti?

Credo che la linea di demarcazione sia in realtà abbastanza semplice.

L’AI dovrebbe fare il lavoro che beneficia della velocità, della scala e della coerenza. Passare attraverso grandi quantità di dati, mettere insieme segnali, individuare pattern, segnalare cose che sembrano fuori posto, aiutare le persone a restringere il campo, questo è esattamente il tipo di lavoro per cui le macchine sono utili. Risparmia tempo, riduce lo sforzo manuale e dà alle squadre di sicurezza un punto di partenza migliore.

È anche adatto alle parti ripetitive del lavoro. Il primo livello di triage. Riassumere i risultati. Collegare questioni simili. Tracciare eccezioni ripetute. Indicare dove certi tipi di debolezza dei controlli continuano ad apparire. Nessuno di questi sostituisce l’esperienza, ma rende un uso migliore di essa.

Dove sarei molto più cauto è quando si passa dall’analisi alla presa di decisioni.

Le chiamate importanti dovrebbero ancora sedere con gli esperti di sicurezza esperti. È veramente un rischio serio in questo business o sembra serio solo in astratto? È una vera debolezza di controllo o è un’eccezione disordinata ma compresa? Se risolviamo questo adesso, cosa altro potremmo interrompere? Se aspettiamo, cosa stiamo realmente accettando? Queste sono chiamate di giudizio.

E questo è prima ancora di arrivare al lato umano di esso. Perché questo continua ad accadere? L’organizzazione sta consapevolmente portando questo rischio o ha semplicemente smesso di notarlo? È un problema isolato o un segno di qualcosa di culturale più in profondità? Quel tipo di interpretazione conta ancora molto.

Quindi, lascerei che l’AI faccia la selezione, la categorizzazione, il primo passaggio, il lavoro pesante. Ma non lascerei che decida cosa l’azienda debba curarsi di più o quale azione debba essere intrapresa senza revisione umana.

Perché una volta che una decisione ha conseguenze, sia operativamente, finanziariamente o reputazionalmente, non si sta più semplicemente elaborando informazioni. Si sta prendendo una decisione.

E nella sicurezza, credo, quella ancora dovrebbe essere una persona con vera intelligenza.

Molte organizzazioni si concentrano ancora fortemente sui conti delle vulnerabilità e sui punteggi di gravità. Perché crede che la gestione dell’esposizione genuina richieda una visione più ampia che includa controlli compensativi, restrizioni di accesso, architettura del sistema e contesto aziendale?

Richiede una visione più ampia perché un numero da solo non ti dice molto su quanto sei veramente in difficoltà.

I punteggi di gravità hanno il loro posto. I conti delle vulnerabilità hanno il loro posto. Aiutano a dimensionare il problema. Aiutano a organizzare il backlog. Ma non sono la stessa cosa della comprensione dell’esposizione, ed è qui che credo che molte organizzazioni ancora sbagliano.

Una vulnerabilità può sembrare grave in teoria e ancora essere relativamente ben contenuta nella pratica. Se l’accesso al sistema è strettamente limitato, se ci sono altri controlli compensativi intorno ad esso, se si trova in una parte dell’ambiente che è difficile da raggiungere attraverso le restrizioni di accesso, allora la reale probabilità che quel problema causi danni può essere molto diversa da quanto suggerisce il punteggio grezzo.

E poi c’è il caso opposto, che è spesso il più interessante. Qualcosa più in basso nella lista può rivelarsi più importante perché di dove si trova. Tocca un servizio critico. È più facile raggiungerlo. Si trova in una parte dell’architettura del sistema in cui un compromesso ti dà spazio per muoverti. Questo è il tipo di cosa che un semplice punteggio di gravità non spiegherà bene.

Quindi, quando la gente parla di gestione dell’esposizione, per me deve significare più che semplicemente ordinare le vulnerabilità per punteggio e lavorare verso il basso della lista.

Bisogna capire cosa si trova intorno al problema. Quali controlli sono già presenti. Chi può raggiungerlo. Se il sistema è isolato o collegato a qualcosa di più importante. E se viene sfruttato, cosa succede veramente dopo.

Altrimenti, si finisce per gestire l’immagine del rischio piuttosto che il rischio stesso. La dashboard migliora. I numeri dei biglietti si muovono. La segnalazione sembra migliore. Ma non si è necessariamente più al sicuro.

Credo che parte del motivo per cui questo accade è che i numeri sono confortanti. Sembra oggettivo. Dà alle persone qualcosa di pulito da presentare. Crea la sensazione che il problema sia stato ridotto a qualcosa di misurabile e sotto controllo. Ma l’esposizione reale è solitamente molto più disordinata di così.

Si trova nell’intersezione tra la debolezza, i controlli intorno ad essa, l’architettura in cui vive e la conseguenza aziendale se qualcosa va storto.

Quindi, sì, usi i punteggi. Usi i conti. Certo. Ma non confondi questi con la comprensione.

Se vuoi sapere dove si trova l’esposizione reale, credo che debba guardare all’intero ambiente, non solo a un numero attaccato ad esso.

Le aziende stanno entrando in un periodo di cambiamento significativo mentre modernizzano i sistemi legacy e adottano contemporaneamente le tecnologie AI. Guardando avanti nei prossimi tre o cinque anni, come vede l’evoluzione della relazione tra AI, sicurezza e piattaforme aziendali, e cosa dovrebbero prepararsi i leader tecnologici oggi?

Credo che i prossimi tre o cinque anni saranno abbastanza definitivi.

Principalmente perché le aziende stanno cercando di modernizzare gli stati patrimoniali legacy allo stesso tempo in cui stanno portando l’AI nel mix, e nessuna di queste due cose è facile da sola. Farle entrambe insieme aumenta gli stake.

Cosa cambia per prima, credo, è che l’AI smette di essere un esperimento laterale e inizia a diventare parte del modo in cui l’azienda funziona veramente. Si presenta nei flussi di lavoro, nel supporto, nello sviluppo, nelle operazioni di sicurezza e nell’amministrazione della piattaforma, non come una novità, ma come parte dell’impiantistica.

E una volta che questo accade, la conversazione sulla sicurezza diventa più seria. Non si chiede più solo se lo strumento sia utile. Si chiede cosa possa raggiungere, cosa possa influenzare, quali dati stia alimentando e quali siano le conseguenze quando si sbaglia.

Credo anche che vedremo la sicurezza e l’architettura diventare ancora più difficili da separare. In molti ambienti più vecchi, la cosa che sembra un problema di sicurezza è spesso in realtà un problema di architettura che indossa un badge di sicurezza. Progettazione di identità debole, troppe dipendenze, proprietà non chiara, integrazioni fragili, scarsa visibilità, queste sono le cose che tendono a stare sotto il problema visibile. L’AI non liscerà questo. Se mai, potrebbe esporre il pasticcio più velocemente.

Quindi, le organizzazioni che gestiscono bene questo, credo, saranno quelle che smettono di trattare l’adozione dell’AI, la sicurezza e la modernizzazione della piattaforma come tre flussi di lavoro separati. Stanno diventando sempre più la stessa conversazione.

Se stessi consigliando i leader tecnologici oggi, inizierei con la visibilità. Devi avere una presa molto più chiara su cosa hai, come si collega, chi ha accesso a cosa, dove si muovono i dati sensibili e dove si trovano i tuoi punti di controllo reali. Senza questo, aggiungere l’AI in cima aumenta solo il numero di cose che non capisci veramente.

La prossima cosa è la governance, ma non il tipo performativo. Decisioni reali. Dove può essere utilizzata l’AI? Dove il giudizio umano deve rimanere in atto? Come vengono verificati gli output? Quali dati sono off-limits? Chi possiede le conseguenze se il sistema guida l’azione sbagliata? Queste domande devono essere risposte ora, non più tardi.

E onestamente, la semplificazione conta più di quanto molte persone vogliano ammettere. Più è intricato lo stato patrimoniale, più è difficile da proteggere, più è difficile da modernizzare e più è difficile utilizzare l’AI senza creare incertezza fresca.

Poi c’è il lato delle persone. Le migliori organizzazioni saranno quelle che sanno come combinare l’automazione con il giudizio. Non consumeranno solo l’output dell’AI perché è veloce o lucido. Lo sfideranno. Lo testeranno. Lo respingeranno quando necessario.

Quindi, sì, nei prossimi anni credo che l’AI, la sicurezza e le piattaforme aziendali diventeranno molto più strettamente legate.

E credo che i leader che si preparano bene saranno quelli che capiscono che questo non è solo uno spostamento tecnologico. È un cambiamento in come vengono prese le decisioni, come viene esercitato il controllo e come è realmente resiliente la loro organizzazione.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Spinnaker Support.