Mark Fetches, CTO på Spinnaker Support – Intervju-serie

Mark Fetches är Chief Technology Officer för EMEA på Spinnaker Support, där han råder företagsorganisationer om teknisk strategi, säkerhet, moln, AI och storskaliga transformationsinitiativ. Med över 30 års erfarenhet av konsult- och ledarskap på Accenture, Deloitte och PwC har Mark arbetat nära med VD:ar och styrelser för att modernisera komplexa företagsmiljöer och anpassa tekniska beslut till långsiktiga affärsmål. Med bas i Storbritannien specialiserar han sig på att hjälpa organisationer att navigera i utmaningar med äldre teknologi, operativ risk och digital transformation med praktisk, affärsinriktad vägledning.

Spinnaker Support är en ledande global leverantör av tredjepartsprogramvarustöd, hanterade tjänster och säkerhetsrådgivning för företag som kör Oracle (ORCL ), SAP, JD Edwards och andra kritiska plattformar.

Du har tillbringat över 20 år med att ge råd till företag på Accenture, Deloitte och PwC innan du blev CTO på Spinnaker Support. När du ser tillbaka på den resan, vad är de största missuppfattningarna som chefer har haft om teknisk risk, och hur har AI förändrat dessa samtal?

Jag tror att den största missuppfattningen alltid har varit att teknisk risk sitter någonstans vid sidan av affären och kan hanteras som en specialistfråga. Jag har aldrig sett det på det sättet.

De allvarligaste riskerna jag har sett kommer från ledningsbeslut. Hur mycket komplexitet man tolererar. Hur beroende man blir av gamla plattformar eller viktiga leverantörer. Hur hårt man trycker på för att öka hastigheten. Om man verkligen litar på de data som affären körs på. Teknologi är där dessa beslut syns, men det är vanligtvis inte där de börjar.

Under åren har jag sett många chefer fokusera på de uppenbara sakerna, såsom cybersäkerhet, regelefterlevnad och kostnadsreducering. Dessa är verkliga problem, naturligtvis. Men de risker som tenderar att fånga företag på bar gärning är ofta tystare än så. Det är plattformen som alla vet är skör men som man fortsätter att skjuta upp att ersätta. Det är dataproblemet som ingen riktigt äger. Det är den utkontrakterade beroendet som ser effektivt ut tills det blir en flaskhals. Dessa saker kan sitta i bakgrunden under år och sedan plötsligt bli mycket synliga när något går fel.

Jag tror också att det har funnits en långvarig vana att förväxla regelefterlevnad med motståndskraft. De är inte samma sak. Du kan klara en revision och fortfarande vara mycket mer utsatt än du tror. En kontrollista berättar inte för dig hur affären kommer att reagera under tryck, hur snabbt den kan återhämta sig eller om ledarna verkligen ser problemet tillräckligt tydligt för att agera.

Vad AI har förändrat är nivån på uppmärksamhet. Dessa samtal satt tidigare längre ner i organisationen. Nu är de mitt i diskussionerna i styrelserummet om tillväxt, förtroende, produktivitet och varumärke. Detta är en mycket bra sak. Men det har också introducerat en ny förenkling, som är idén att AI-modellen som används är risken. Vanligtvis är det större än så. De svårare frågorna handlar om data och styrning runt den, de beslut den påverkar och den punkt där mänsklig bedömning fortfarande måste spela roll.

Så om jag skulle sammanfatta det skulle jag säga att teknisk risk aldrig har varit bara en teknisk fråga. Den har alltid varit en reflektion av ledningsbedömning. AI har bara gjort det svårare att ignorera.

Säkerhetsteam har nu tillgång till mer sårbarhetsinformation än någonsin tidigare, men organisationer fortsätter att kämpa med prioritering. Varför tror du att branschen har ett signal-till-brus-problem snarare än ett upptäcktsproblem?

Jag skulle säga att branschen inte lider av brist på sårbarhetsdata. Den lider av brist på tydlighet.

De flesta säkerhetsteam har redan mer än tillräckligt med indata, skanningsutdata, hotinformation, allvarlighetspoäng, patchråd och exploateringsrapporter. Problemet är inte om de kan hitta svagheter. Det är om de kan skilja de få som verkligen kan skada affären från de många som är tekniskt intressanta men mindre konsekventa.

Det är därför jag ser det som ett signal-till-brus-problem. Upptäckt har förbättrats avsevärt. Vad som inte har hållit jämna steg är förmågan att tillämpa sammanhang. En sårbarhet blir bara en verklig prioritet när du förstår var den sitter, hur utsatt den är, hur kritisk tillgången är, vilka kompenserande kontroller som finns och vilken affärspåverkan det skulle ha om den utnyttjades.

I praktiken faller många organisationer fortfarande tillbaka på de mått som är lättast att producera, såsom allvarlighetspoäng, patchantal och åldersrapporter. Dessa är användbara, men de är inte samma sak som mänsklig bedömning. En högt rankad fråga i ett lågt värdesystem kan vara mindre viktig än en lägre rankad svaghet som sitter på något kundorienterat eller operativt kritiskt.

Så, jag tror inte att detta i grunden är ett synlighetsproblem. Det är ett affärsprioriteringsproblem som behöver läras av säkerhetsteam. Vi har blivit mycket bra på att generera fynd. Vi är fortfarande mindre konsekventa i att översätta dessa fynd till en kort lista med åtgärder som ledningen kan stödja med tillförsikt.

Från min synvinkel är detta den verkliga skiftet som branschen fortfarande behöver göra, ett steg bort från att mäta hur mycket vi kan upptäcka mot att bestämma vad som verkligen är viktigt i termer av affärspåverkan.

På styrelsenivå är detta verkligen en fråga om risköversättning, kan organisationen omvandla teknisk exponering till ett litet antal tydliga, agerbara affärsprioriteringar? De som kan göra det är de som flyttar från brus till signal.

Många cybersäkerhetsleverantörer hävdar att AI kan automatiskt prioritera sårbarheter och förutsäga hot. Var ser du klyftan mellan marknadsberättelsen och vad AI realistiskt kan leverera i dag i företagsmiljöer?

Jag tror att det enklaste sättet att uttrycka det är att marknadsföringen tenderar att lova en nivå av säkerhet som verkliga företagsmiljöer helt enkelt inte tillåter.

Leverantörer beskriver ofta AI som om den kan höja sig över bruset, ta in allt och tillförlitligt berätta för säkerhetsteamet vad som är viktigast och vad som troligen kommer att hända nästa. Det är en övertygande pitch eftersom varje säkerhetsledare vill ha mindre brus och mer tillförsikt. Men när du kommer in i en stor organisation är saker och ting sällan så rena att löftet kan hållas på ett sådant enkelt sätt.

AI kan absolut hjälpa. Det kan dra samman mönster, minska en del av den manuella sorteringen, lyfta fram avvikelser och hjälpa team att arbeta igenom volymer av information som annars skulle vara svåra att hantera, och detta har verkligt värde. Men det finns en skillnad mellan att hjälpa ett team att flytta snabbare och att verkligen veta, med någon form av tillförlitlig precision, vad som bör vara viktigast i den specifika miljön.

Det är där klyftan dyker upp. De flesta företag är fulla av ojämn kontext. Tillgångsinventeringar är ofullständiga. Ägandeskap är inte alltid tydligt. Affärskritikalitet förändras. Kontroller varierar från en del av fastigheten till en annan. Datakvalitet är blandad. Om den underliggande bilden är fläckig, då kommer AI:s utdata att vara fläckig också, oavsett hur polerad gränssnittet kan se ut.

Jag tror att detta är särskilt sant när leverantörer pratar om förutsägelse. Det finns en meningsfull skillnad mellan att säga “denna mönster ser riskabelt ut” och att säga “detta är vad som kommer att hända nästa”. Det första kan vara användbart. Det andra är där språket ofta springer före verkligheten.

Så, för mig är AI bäst förstådd i dag som en förstärkare, inte en auktoritet. Det kan hjälpa team att sortera, korrelera och fokusera. Vad det inte kan göra konsekvent är att ersätta behovet av mänsklig bedömning, lokal kunskap och en tydlig förståelse för vad affären verkligen bryr sig om.

Det är verkligen skiljelinjen. Berättelsen föreslår säkerhet. Verkligheten är mer blygsam och mer användbar än hypen om du är ärlig om det. AI kan förbättra kvaliteten och hastigheten på analysen, men det tar inte bort besvärligheten i företagssäkerhetsbeslut.

Spinnaker Support arbetar omfattande med Oracle, SAP och JD Edwards-distributioner. Vad gör högt anpassade ERP-miljöer särskilt svåra för AI-drivna säkerhetsverktyg att förstå och bedöma korrekt?

Vad som gör dessa miljöer svåra är att de, efter tillräckligt många år, slutar bete sig som standardprogramvara som AI har tränats på och börjar bete sig mer som en post om hur affären verkligen fungerar.

Jag har sett att detta är särskilt sant i tungt anpassade Oracle-, SAP- och JD Edwards-miljöer. På papper kan du fortfarande titta på en känd plattform. I verkligheten tittar du ofta på år av lokala anpassningar, anpassad kod, ärvt integrering, behörighetsstrukturer, rapportlogik och lösningar byggda för mycket specifika operativa skäl. För ett AI-drivet säkerhetsverktyg kan detta vara svårt att läsa med någon form av tillförsikt.

Många av dessa verktyg fungerar bäst när miljön är relativt konsekvent och mönstren är lättare att jämföra. Höggradigt anpassade ERP-miljöer är sällan sådana. Logiken är mer invecklad. Dokumentationen är ofta ofullständig. Ägandeskap kan vara spritt över team. Vad som ser ovanligt ut kan vara fullständigt avsiktligt och vad som ser rutinmässigt ut kan visa sig vara kritiskt i finans, leverantörskedja eller drift.

Detta är där svårigheten ligger. Verktyget är inte bara tillfrågat om att upptäcka en sårbarhet eller en felkonfiguration. Det är tillfrågat om att förstå vad problemet betyder i sammanhanget av en affärsprocess, en anpassad beroende eller en kontrollstruktur som kanske inte finns någon annanstans.

Och det är ett mycket svårare problem än vad marknadsföringen vanligtvis antyder. AI kan absolut hjälpa till att yta mönster, minska en del av den manuella analysen och peka team mot områden som är värda att titta närmare på. Men om fastigheten bara är delvis dokumenterad, formad av år av undantag och djupt knuten till hur företaget fungerar, finns det en gräns för hur korrekt ett automatiserat system kan tolka det på egen hand.

Så, jag tror att det verkliga problemet inte är om AI kan se något. Det är om det kan förstå tillräckligt av den omgivande kontexten för att bedöma det korrekt. I högt anpassade ERP-miljöer är det fortfarande där mänsklig expertis gör skillnaden.

En av dina huvudargument är att mänsklig expertis inte är en flaskhals att eliminera, utan en väsentlig del av säkerhetsprocessen. Kan du dela exempel där mänsklig bedömning identifierade risker som en AI-driven prioriteringsmotor sannolikt skulle ha missat?

Ja, absolut. Och för mig är detta där gränserna för automatiserad prioritering blir mycket uppenbara.

Vissa risker förstår sig bara när du känner miljön tillräckligt bra för att förstå vad som ligger bakom data. Ett system kan inte se särskilt viktigt ut från utsidan. Sårbarhetsscoren kan vara oanmärkningsvärd. Men någon som känner fastigheten kan veta att det stöder lönehantering, kvartalsvisa rapporter, en skör integration eller en affärsprocess som företaget helt enkelt inte kan avbryta. Signalen i data kan se vanlig ut. Den verkliga världskonsekvensen är inte.

Jag har också sett fall där kontrollbilden ser bättre ut i teorin än den gör i praktiken. En AI-motor kan anta att en risk är reducerad eftersom segmentering är på plats, eller eftersom åtkomst är begränsad, eller eftersom en övervakningskontroll finns. Men en person nära miljön kan veta att en kontroll är inkonsekvent tillämpad, en annan kringgås när operationer är under tryck och en tredje har tystnat vara tillförlitlig. Den typen av lucka syns inte alltid rent i systemet.

Detsamma händer i anpassade miljöer. Ett skript, en arbetsflöde eller en behörighetsmodell kan se rutinmässig ut om du skannar efter mönster i skala. För någon som förstår hur systemet har anpassats över tid kan samma detalj stå ut omedelbart som en verklig källa till exponering.

Timing är också viktigt. En sårbarhet kan se hanterbar ut i isolering, sedan bli mycket allvarligare eftersom affären är mitt i en migration, en förvärv, en regulatorisk deadline eller en toppdriftsperiod. Den typen av skift är inte alltid lätt för en automatiserad motor att tolka med rätt vikt.

Så, när jag pratar om mänsklig expertis, pratar jag inte om instinkt i någon vag mening. Jag menar lokal kunskap. Minne. Bedömning. Förmågan att se när ett litet tekniskt problem är kopplat till något mycket mer konsekvent.

Det är därför jag inte ser mänsklig expertis som en flaskhals att ta bort. Jag ser det som den del som förhindrar falsk tillförsikt. AI kan hjälpa till att sortera och minska data. Men de risker som betyder mest är ofta de som bara blir uppenbara när någon förstår hur affären verkligen fungerar.

När organisationer rusar för att anta AI över hela säkerhetsdriften, vad är de största riskerna med att överautomatisera sårbarhetshantering och exponeringsbedömning?

Den största risken jag ser är att du skapar en illusion av kontroll utan verkligheten av att förstå att du är i kontroll.

Sårbarhetsshantering är ett område där automation är uppenbarligen värdefullt. I företagsmiljöer behöver du automation för att hitta problem, korrelera data, prioritera i volym och hålla hela processen i rörelse. Inget allvarligt företag kan hantera det manuellt.

Men faran kommer när automation börjar driva programmet utan tillräckligt med mänsklig utmaning runt det.

Det första uppenbara risken är felaktig prioritering. Om du förlitar dig för mycket på automatiserad poängsättning kan du börja behandla teknisk allvarlighet som om det vore samma sak som affärsrisk. Det är det inte. En kritisk sårbarhet på ett isolerat eller kompenserat kontrollerat tillgång kan vara mindre viktigt i praktiken än en lägre rankad fråga som sitter på ett högt exponerat system kopplat till en kritisk affärsprocess.

Det andra risken jag ser är förlust av kontext. Automatiserade program är bara så bra som tillgångsdata, ägandeskapsdata, beroendekartor och undantagshantering bakom dem. Om den underliggande informationen är ofullständig, och i de flesta företag är den ofta det, då kan automationen bli mycket effektiv på att flytta felaktiga beslut genom systemet.

Det tredje risken är beteendemässig. När människor börjar lita för mycket på arbetsflödet slutar de att ifrågasätta dess utdata. Team antar att vad som stiger till toppen måste vara vad som betyder mest och vad som inte stiger till toppen kan vänta. Det är förståeligt, men jag tror det är farligt. Eftersom det skiftar kulturen från informerad riskhantering till passiv acceptans av maskinledd ordning.

Och sedan finns det en bredare strategisk risk, som är att organisationer börjar förväxla genomströmning med säkerhetsförbättring. Att stänga en stor mängd sårbarheter ser bra ut operativt. Det skapar instrumentpaneler, mått och en känsla av momentum. Men om du inte minskar de exponeringar som betyder mest för affären, kan du bara bli snabbare på att se upptagen ut.

Så, min uppfattning är att automation bör absolut göra det tunga arbetet. Men det bör stödja bedömning, inte ersätta det. Annars hamnar du med en process som är effektiv, mätbar och skalbar, men inte nödvändigtvis säkrare.

Du har arbetat omfattande inom IT-transformation och företagsarkitektur. Hur bör CISO:er balansera behovet av att patcha sårbarheter snabbt mot de operativa riskerna med att störa kritiska affärssystem?

Bra fråga, eftersom detta är ett område där det enkla svaret vanligtvis är fel.

Det är naturligtvis att du vill patcha snabbt. Inget CISO kommer att argumentera för att sitta på kända sårbarheter längre än nödvändigt. Men i en verklig företagsmiljö, särskilt en som kör kritiska system, är hastighet på egen hand inte målet. Om du patchar illa och tar ner något som affären förlitar sig på, har du löst ett problem genom att skapa ett annat.

Så, balansen handlar verkligen om att förstå vilka risker som är levande, vilka som är teoretiska och vilka system som kan tolerera förändringar utan att orsaka problem någon annanstans.

Vissa sårbarheter behöver verkligen brådskande åtgärd. Om något är exponerat, exploaterbart och sitter i en del av fastigheten som betyder något, då flyttar du. Men de flesta gånger är beslutet mindre absolut än vad människor gör det till. Du kan ha andra kontroller runt frågan. Det påverkade systemet kan vara tätt inneslutet. Den operativa risken för att göra förändringen idag kan vara högre än att hålla positionen under en kort period och göra det ordentligt.

Det är därför de bättre CISO:erna tenderar att vara de som kan ha en vuxen konversation med affären. Inte bara “Detta är kritiskt, patcha det nu”, utan “Här är exponeringen, här är vad som kan hända, här är vad som kan gå fel om vi ingriper illa och här är den säkraste vägen genom det.” Det är en mer trovärdig form av ledarskap än att behandla varje sårbarhet som om den existerar i isolering.

Jag tror också att dessa ögonblick avslöjar något djupare om fastigheten i sig. Om en organisation är konstant rädd för att patcha kritiska system eftersom varje förändring känns farlig, berättar det vanligtvis att miljön har blivit skör. För mycket dold beroende, inte tillräckligt med testkonfidens, för lite motståndskraft i arkitekturen. I den situationen är patchningsdebatten verkligen ett symptom på ett mycket äldre problem.

Så, ja, patcha snabbt där risken är verklig och vägen är tydlig. Men där miljön är känslig, är jobbet att minska risken utan att skapa en större röra. Detta är balansen.

Och för att vara ärlig, de flesta erfarna CISO:er vet redan detta. Utmaningen är att tillämpa deras beslut under tryck, när klockan tickar och ingen vill äga konsekvenserna av att göra fel.

Spinnakers tillvägagångssätt kombinerar AI-driven analys med expertvalidering. Vilka specifika uppgifter bör AI hantera, och vilka beslut bör förbli fast i händerna på erfarna säkerhetsproffs?

Jag tror att skiljelinjen är faktiskt ganska enkel.

AI bör göra det arbete som drar nytta av hastighet, skala och konsekvens. Gå igenom stora mängder data, dra samman signaler, identifiera mönster, flagga saker som ser avvikande ut, hjälpa människor att begränsa fältet, detta är exakt det arbete som maskiner är användbara för. Det sparar tid, det minskar manuellt arbete och det ger säkerhetsteam en bättre utgångspunkt.

Det är också väl lämpat för de repetitiva delarna av jobbet. Den första nivån av triage. Sammanfattning av fynd. Anslutning av liknande frågor. Spårning av återkommande undantag. Pekande på var vissa typer av kontrollsvaghet fortsätter att dyka upp. Inget av detta ersätter expertis, men det gör bättre användning av den.

Där jag skulle vara mycket mer försiktig är när du flyttar från analys till beslutsfattande.

De viktiga besluten bör fortfarande sitta med erfarna säkerhetsproffs. Är detta verkligen en allvarlig risk i den här affären eller ser det bara allvarligt ut i abstrakt? Är detta en verklig kontrollfel eller är det en rörig men förstådd undantag? Om vi fixar detta nu, vad annat kan vi störa? Om vi väntar, vad accepterar vi verkligen? Dessa är bedömningsbeslut.

Och det är innan du ens kommer till den mänskliga sidan av det. Varför händer detta? Har organisationen medvetet burit denna risk eller har den bara slutat märka den? Är detta en isolerad fråga eller ett tecken på något kulturellt underliggande? Den typen av tolkning betyder fortfarande en hel del.

Så, jag skulle låta AI göra sorteringen, klusterbildningen, den första passagen, det tunga lyftet. Men jag skulle inte låta det bestämma vad affären bör bry sig om mest eller vilken åtgärd som bör vidtas utan mänsklig granskning.

För när ett beslut har konsekvenser, antingen operativt, finansiellt eller reputationsmässigt, är du inte längre bara bearbetar information. Du fattar ett beslut.

Och i säkerhet, tror jag, bör det fortfarande vara en person med verklig intelligens.

Många organisationer fokuserar fortfarande tungt på sårbarhetsantal och allvarlighetspoäng. Varför tror du att äkta exponeringshantering kräver en bredare vy som inkluderar kompenserande kontroller, åtkomstbegränsningar, systemarkitektur och affärssammanhang?

Det kräver en bredare vy eftersom ett nummer på egen hand inte berättar mycket om hur mycket problem du verkligen är i.

Allvarlighetspoäng har sin plats. Sårbarhetsantal har sin plats. De hjälper dig att storleksbestämma problemet. De hjälper dig att organisera köan. Men de är inte samma sak som att förstå exponering, och det är där jag tror att många organisationer fortfarande får det fel.

En sårbarhet kan se allvarlig ut i teorin och fortfarande vara relativt väl innesluten i praktiken. Om åtkomst till systemet är tätt begränsad, om det finns andra kompenserande kontroller runt det, om det sitter i en del av miljön som är svår att nå genom åtkomstbegränsningar, då kan den faktiska sannolikheten för att problemet orsakar skada vara ganska annorlunda än vad den rena poängen antyder.

Och sedan får du det motsatta fallet, som ofta är det mer intressanta. Något lägre ner på listan kan visa sig betyda mycket mer eftersom det sitter på en kritisk tjänst, är lättare att nå, sitter i en del av systemarkitekturen där en kompromiss ger utrymme att röra sig. Det är den typen av sak som en enkel allvarlighetsrankning inte kommer att förklara väl.

Så, när människor pratar om exponeringshantering, menar jag att det måste betyda mer än bara att sortera sårbarheter efter poäng och arbeta neråt högen.

Du behöver veta vad som sitter runt frågan. Vilka kontroller som redan finns. Vem kan nå det. Om systemet är isolerat eller kopplat till något viktigare. Och om det utnyttjas, vad händer verkligen sedan.

Annars hamnar du med att hantera bilden av risk snarare än risken i sig. Instrumentpanelen förbättras. Biljett numren flyttar. Rapporteringen ser bättre ut. Men du är inte nödvändigtvis säkrare.

Jag tror att en del av anledningen till att detta händer är att nummer är bekväma. De ser objektiva ut. De ger människor något prydligt att presentera. De skapar en känsla av att problemet har reducerats till något mätbart och under kontroll. Men verklig exponering är vanligtvis mycket rörigare än så.

Det sitter i överlappet mellan felet, kontrollerna runt det, arkitekturen det bor i och affärskonsekvensen om något går fel.

Så, ja, använd poängen. Använd antalet. Naturligtvis. Men förväxla dem inte med förståelse.

Om du vill veta var den verkliga exponeringen är, tror jag att du måste titta på hela miljön, inte bara ett nummer fäst vid den.

Företagsprogramvarumiljöer går in i en period av betydande förändring när organisationer moderniserar äldre system samtidigt som de antar AI-teknologier. När du ser framåt de kommande tre till fem åren, hur ser du på relationen mellan AI, cybersäkerhet och företagsplattformar utvecklas, och vad bör tekniska ledare förbereda sig på i dag?

Jag tror att de kommande tre till fem åren kommer att vara ganska avgörande.

Först och främst för att företag försöker modernisera gamla företagsfastigheter samtidigt som de för in AI i mixen, och ingen av dessa saker är lätt på egen hand. Att göra båda samtidigt höjer insatserna.

Vad som förändras först, tror jag, är att AI slutar vara en sidouppgift och börjar bli en del av hur affären verkligen körs. Det visar sig i arbetsflöden, support, utveckling, säkerhetsdrift och plattformsadministration, inte som en nyhet, utan som en del av rörledningen.

Och när det händer, blir cybersäkerhetssamtalet allvarligare. Du är inte bara tillfrågad om verktyget är användbart. Du är tillfrågad om vad det kan nå, vad det kan påverka, vilken data det matas med och vilka konsekvenserna är när det får något fel.

Jag tror också att vi kommer att se säkerhet och arkitektur bli ännu svårare att skilja åt. I många äldre miljöer är det som ser ut som ett säkerhetsproblem ofta i själva verket ett arkitekturproblem som bär ett säkerhetsmärke. Svag identitetsdesign, för många beroenden, oklart ägandeskap, skör integrering, dålig synlighet, det är de saker som tenderar att sitta under det synliga problemet. AI kommer inte att släta över det. Om något, kan det utsätta röran snabbare.

Så, organisationerna som hanterar detta väl, tror jag, kommer att vara de som slutar behandla AI-antagande, cybersäkerhet och plattformsmodernisering som tre separata arbetsflöden. De är alltmer samma samtal.

Om jag skulle ge råd till tekniska ledare nu, skulle jag börja med synlighet. Du behöver en mycket tydligare förståelse för vad du har, hur det kopplar samman, vem som har åtkomst till vad, var känslig data flyttar och var dina verkliga kontrollpunkter är. Utan det, lägga AI ovanpå bara ökar antalet saker du inte fullständigt förstår.

Nästa sak är styrning, men inte den performativa sorten. Verkliga beslut. Var kan AI användas? Var behöver mänsklig granskning förbli på plats? Hur kontrolleras utdata? Vilken data är utanför gränsen? Vem äger konsekvenserna om systemet driver fel åtgärd? Dessa frågor behöver besvaras nu, inte senare.

Och ärligt talat, förenkling betyder mer än vad många människor vill medge. Ju mer invecklad fastigheten är, desto svårare är det att säkra, desto svårare är det att modernisera och desto svårare är det att använda AI utan att skapa ny osäkerhet.

Sedan finns det den mänskliga sidan av det. De bättre organisationerna kommer att vara de som vet hur man kombinerar automation med bedömning. De kommer inte att konsumera AI-utdata bara för att det är snabbt eller polerat. De kommer att utmana det. Testa det. Trycka tillbaka på det när det behövs.

Så, ja, under de kommande åren tror jag att AI, cybersäkerhet och företagsplattformar kommer att bli alltmer tätt bundna samman.

Och jag tror att de ledare som förbereder sig väl kommer att vara de som förstår att detta inte bara är en teknisk skift. Det är en förändring i hur beslut fattas, hur kontroll utövas och hur motståndskraftig deras organisation verkligen är.

Tack för det underbara intervjun, läsare som vill lära sig mer bör besöka Spinnaker Support.