Mark Fetches, CTO i Spinnaker Support – Intervju-serie

Mark Fetches er Chief Technology Officer for EMEA i Spinnaker Support, der han rådgiver enterprise-organisasjoner om teknologistrategi, sikkerhet, sky, AI og store transformasjonsinitiativer. Med mer enn 30 års erfaring som konsulent og leder i Accenture, Deloitte og PwC, har Mark arbeidet nært med C-suite-eksikutive og styre for å modernisere komplekse enterprise-miljøer og harmonisere teknologibeslutninger med langsiktige forretningsmål. Basert i Storbritannia, spesialiserer han seg på å hjelpe organisasjoner med å navigere i utfordringer med legacy-teknologi, operasjonell risiko og digital transformasjon med praktisk, forretningsorientert veiledning.

Spinnaker Support er en ledende global leverandør av tredjepartsprogramvare-støtte, managed services og sikkerhetsrådgivning for bedrifter som kjører Oracle (ORCL ), SAP, JD Edwards og andre kritiske plattformer.

Du har brukt over 20 år på å rådgive bedrifter i Accenture, Deloitte og PwC før du ble CTO i Spinnaker Support. Ser du tilbake på denne reisen, hva er de største misforståelsene ledere har hatt om teknologirisk, og hvordan har AI-endringen forandret disse samtalene?

Jeg tror den største misforståelsen alltid har vært at teknologirisk ligger utenfor forretningsområdet og kan håndteres som en spesialistproblematikk. Jeg har aldri sett på det på den måten.

De fleste alvorlige risikoer jeg har sett, kommer fra ledelsesbeslutninger. Hvor mye kompleksitet du tolererer. Hvor avhengig du blir av gamle plattformer eller nøkkelleverandører. Hvor hardt du presser på for å få fart. Om du virkelig stoler på dataene forretningsområdet kjører på. Teknologi er der disse beslutningene viser seg, men det er sjelden der de starter.

Over årene har jeg sett mange ledere fokusere på de åpenbare tingene som cyber, compliance og kostnadsreduksjon. Disse er viktige problemer, selvfølgelig. Men risikoene som vanligvis tar bedrifter med overraskelse, er ofte mer diskrete enn det. Det er plattformen alle vet er skjør, men fortsatt utsetter å erstatte. Det er dataproblemet ingen eier. Det er den outsourcende avhengigheten som ser effektiv ut til å begynne med, men blir en flaskehals når det virkelig teller. Disse tingene kan ligge i bakgrunnen i årevis og bli plutselig svært synlige når noe går galt.

Jeg tror også det har vært en langvarig vane å forveksle compliance med resilient. De er ikke det samme. Du kan bestå en audit og likevel være mye mer utsatt enn du tror. En sjekkeliste forteller deg ikke hvordan forretningsområdet vil reagere under press, hvor raskt det kan gjenopprettes, eller om ledere virkelig ser problemet tydelig nok til å handle.

Hva AI har endret, er nivået av oppmerksomhet. Disse samtalen lå tidligere lenger nede i organisasjonen. Nå er de rett i midten av diskusjonene i styret om vekst, tillit, produktivitet og merkevare. Dette er en svært god ting. Men det har også introdusert en ny forenkling, som er ideen om at AI-modellen som brukes, er risikoen. Vanligvis er det større enn det. De vanskelige spørsmålene handler om dataene og styringen rundt det, beslutningene det påvirker og punktet hvor menneskelig dømmekraft fortsatt må være avgjørende.

Så hvis jeg skulle sammenfatte det, ville jeg si at teknologirisk har aldri virkelig vært om teknologien alene. Det har alltid vært en refleksjon av ledelsesdømmekraft. AI har bare gjort det vanskeligere å ignorere.

Sikkerhetsteam har nå tilgang til mer sårbarhetsinformasjon enn noen gang før, men organisasjoner fortsetter å struggle med prioritering. Hvorfor tror du industrien har et signal-til-støy-problem i stedet for et oppdagingproblemer?

Jeg ville si det meget enkelt, industrien mangler ikke sårbarhetsdata. Det er kort på klarhet.

De fleste sikkerhetsteam har allerede mer enn nok innputt, skanningsutdata, trusselintelligens, alvorlighetspoeng, patch-råd, utnyttelsesrapportering. Problemet er ikke om de kan finne svakheter. Det er om de kan skille de få som virkelig kan skade forretningsområdet fra de mange som er teknisk interessante, men mindre konsekvensfulle.

Dette er hvorfor jeg ser på det som et signal-til-støy-problem. Oppdaging har forbedret seg enormt. Hva som ikke har holdt tritt, er evnen til å anvende kontekst. En sårbarhet blir bare en virkelig prioritet når du forstår hvor den sitter, hvor utsatt den er, hvor kritisk den påvirkede ressursen er, hva kompenserende kontroller finnes, og hva forretningskonsekvensen ville være hvis den ble utnyttet.

I praksis faller mange organisasjoner tilbake på de målinger som er enklest å produsere, som alvorlighetspoeng, patch-tellinger og aldringsrapporter. Disse er nyttige, men de er ikke det samme som menneskelig dømmekraft. En høyt-scoring sak i et lav-verdi internsystem kan være mindre viktig enn en lavere-vurdert svakhet som sitter på noe kunde-orientert eller operasjonelt kritisk.

Så, jeg tror ikke dette er fundamentalt et synlighetsproblem. Det er et forretningsprioriteringsproblem som må læres av sikkerhetsteam. Vi har blitt svært gode til å generere funn. Vi er fortsatt mindre konsistente til å oversette disse funnene til en kort liste over handlinger som ledelse kan støtte med tillit.

Og fra min perspektiv er dette den virkelige skiftet industrien fortsatt må gjøre, en bevegelse bort fra å måle hvor mye vi kan oppdage mot å bestemme hva som virkelig betyr noe i forretningskonsekvens.

På styrenivå er dette virkelig et spørsmål om risikotolkning, kan organisasjonen omgjøre teknisk eksponering til et lite antall klare, handlebare forretningsprioriteter? De som kan gjøre det, er de som flytter fra støy til signal.

Mange sikkerhetsleverandører hevder at AI kan automatisk prioritere sårbarheter og forutsi trusler. Hvor ser du gapet mellom markedsføringsnarrativen og hva AI realistisk kan levere i dag i enterprise-miljøer?

Jeg tror det enkleste måten å si det på er at markedsføringen rundt dette lover en nivå av sikkerhet som virkelige enterprise-miljøer bare ikke tillater.

Leverandører beskriver ofte AI som om det kan heve seg over støyen, ta inn alt og pålitelig fortelle sikkerhetsteam hva som betyr mest og hva som sannsynligvis vil skje neste. Det er en overbevisende salgsargument fordi hver sikkerhetsleder ønsker mindre klus og mer tillit. Men en gang du kommer inn i en stor organisasjon, er ting sjelden så enkle som det løftes frem i markedsføringen.

AI kan absolutt hjelpe. Det kan trekke mønster sammen, redusere noe av den manuelle sorteringen, høydepunkte områder verdt en nærmere titt og hjelpe team med å gå gjennom mengder av informasjon som ellers ville være vanskelige å håndtere, og dette har virkelig verdi. Men det er en forskjell på å hjelpe et team med å flytte raskere og å vite, med noen pålitelig nøyaktighet, hva som bør bety mest i det spesifikke miljøet.

Dette er hvor gapet viser seg. De fleste bedrifter er fulle av ujevne kontekster. Asset-inventarer er ufullstendige. Eierskap er ikke alltid klart. Forretningskritikalitet endrer seg. Kontroller varierer fra ett område av eiendommen til et annet. Datakvalitet er blandet. Hvis den underliggende bildet er flekket, så vil AI-utgangen også være flekket, uansett hvor polert grensesnittet må se ut.

Jeg tror dette er spesielt sant når leverandører snakker om forutsigelse. Det er en betydelig forskjell på å si “dette mønsteret ser risikabelt ut” og å si “dette er hva som vil skje neste”. Det første kan være nyttig. Det siste er der språket ofte løper foran virkeligheten.

Så, for meg er AI best forstått i dag som en forsterker, ikke en autoritet. Det kan hjelpe team med å sortere, korrelere og fokusere. Hva det ikke kan gjøre konsekvent, er å erstatte behovet for menneskelig dømmekraft, lokal kunnskap og en klar forståelse av hva forretningsområdet virkelig bryr seg om.

Dette er virkelig skillelinjen. Narrativen foreslår sikkerhet. Virkeligheten er mer beskjeden og mer nyttig enn hypen hvis du er ærlig om det. AI kan forbedre kvaliteten og hastigheten på analysen, men det fjerner ikke uroen i enterprise-sikkerhetsbeslutninger.

Spinnaker Support arbeider omfattende med Oracle, SAP og JD Edwards-utsteder. Hva gjør høyt tilpassede ERP-miljøer spesielt vanskelige for AI-drevne sikkerhetstverktøy å forstå og vurdere nøyaktig?

Hva som gjør disse miljøene vanskelige, er at de etter nok år slutter å oppføre seg som standard programvare som AI er trent på, og begynner å oppføre seg mer som en registrering av hvordan forretningsområdet virkelig fungerer.

Jeg har sett dette være spesielt sant i høyt tilpassede Oracle-, SAP- og JD Edwards-estater. På papir kan du fortsatt se på en kjent plattform. I virkeligheten ser du ofte på år med lokale tilpasninger, tilpasset kode, arvet integrasjoner, tillatelsesstrukturer, rapporteringslogikk og midler bygget for svært spesifikke operative årsaker. For et AI-drevet sikkerhetstverktøy kan dette være vanskelig å lese med noen virkelig tillit.

Mange av disse verktøyene fungerer best når miljøet er relativt konsistent og mønstrene er enklere å sammenligne. Høyt tilpassede ERP-miljøer er sjelden som det. Logikken er mer sammenfiltret. Dokumentasjonen er ofte ufullstendig. Eierskap kan være spredt over team. Hva som ser uvanlig ut, kan være fullstendig meningsfullt og hva som ser vanlig ut, kan vise seg å være kritisk i finans, leveringskjede eller operasjoner.

Dette er hvor vanskeligheten ligger. Verktøyet er ikke bare bedt om å spore en sårbarhet eller en miskonfigurasjon. Det er bedt om å forstå hva problemet betyr i konteksten av en forretningsprosess, en tilpasset avhengighet eller en kontrollstruktur som kanskje ikke finnes noe annet sted.

Og det er et mye vanskeligere problem enn det markedsføringen vanligvis antyder. AI kan hjelpe med å trekke mønster sammen, redusere noe av den manuelle analysen og peke team mot områder verdt en nærmere titt. Men hvis eiendommen bare delvis er dokumentert, formet av år med unntak og dypt knyttet til måten bedriften opererer, er det en grense for hvor nøyaktig et automatisert system kan tolke det på egen hånd.

Så, jeg tror det virkelige problemet er ikke om AI kan se noe. Det er om det kan forstå nok av den omgivende konteksten til å dømme det ordentlig. I høyt tilpassede ERP-miljøer er det fortsatt hvor menneskelig ekspertise gjør en forskjell.

En av dine viktigste argumenter er at menneskelig ekspertise ikke er en flaskehals å eliminere, men en essensiell del av sikkerhetsprosessen. Kan du dele eksempler hvor menneskelig dømmekraft identifiserte risikoer som en AI-drevet prioriteringsmotor sannsynligvis ville ha gått glipp av?

Ja, absolutt. Og for meg er dette hvor grensene for automatisert prioritering blir svært åpenbare.

Noen risikoer betyr bare noe når du kjenner miljøet godt nok til å forstå hva som ligger bak dataene. Et system kan se ubetydelig ut fra utsiden. Sårbarhetsscoren kan være uanselig. Men noen som kjenner eiendommen, kan vite at det støtter lønn, kvartalsvis rapportering, en skjør integrasjon eller en forretningsprosess som bedriften bare ikke kan avbryte. Signalet i dataene kan se vanlig ut. Den virkelige konsekvensen er ikke.

Jeg har også sett tilfeller hvor kontrollbildet ser bedre ut i teorien enn det gjør i praksis. En AI-motor kan anta at en risiko er redusert fordi segmentering er på plass, eller fordi tilgang er begrenset eller fordi en overvåkingskontroll finnes. Men noen som er nær miljøet, kan vite at en kontroll er inkonsistent anvendt, en annen er omgått når operasjoner er under press, og en tredje har stille og rolig sluttet å være pålitelig. Den type gap viser ikke alltid opp i systemet av record.

Dette skjer også i tilpassede miljøer. Et script, en arbeidsflyt eller en tillatelsesmodell kan se vanlig ut hvis du scannar etter mønster i stor skala. For noen som forstår hvordan systemet er tilpasset over tid, kan samme detalj stå ut umiddelbart som en virkelig kilde til eksponering.

Tidspunkt betyr også noe. En sårbarhet kan se håndterbar ut i isolasjon, så bli mye mer alvorlig fordi forretningsområdet er midt i en migrasjon, en akuisisjon, en regulatorisk frist eller en topp operasjonsperiode. Den type skift er ikke alltid enkelt for en automatisert motor å tolke med riktig vekt.

Så, når jeg snakker om menneskelig ekspertise, snakker jeg ikke om instinkt i noen vag forstand. Jeg mener lokal kunnskap. Hukommelse. Dømmekraft. Evnen til å se når et lite teknisk problem er koblet til noe mye mer konsekvensfullt.

Dette er hvorfor jeg ikke ser på menneskelig ekspertise som en flaskehals å fjerne. Jeg ser på det som den delen som forhindrer feil tillit. AI kan hjelpe med å sortere og snevre dataene. Men risikoene som betyr mest, er ofte de som bare blir åpenbare når noen forstår hvordan forretningsområdet virkelig fungerer.

Ettersom organisasjoner skynder seg for å adoptere AI over hele sikkerhetsoperasjonene, hva er de største risikoene med å over-automatisere sårbarhetsstyring og eksponeringsvurdering?

Den største risikoen jeg ser, er at du skaper inntrykket av kontroll uten virkeligheten av å virkelig forstå at du er i kontroll.

Sårbarhetsstyring er ett av områdene hvor automatisering er åpenbart verdifullt. På bedriftsnivå trenger du automatisering for å finne problemer, korrelere data, prioritere i stor skala og holde hele prosessen i gang. Ingen alvorlig organisasjon kan håndtere det manuelt.

Men faren kommer når automatisering begynner å drive programmet uten nok menneskelig utfordring rundt det.

Det første åpenbare risikoen er feil prioritering. Hvis du avhenger for mye av automatisert scoring, kan du ende opp med å behandle teknisk alvorlighet som om det var det samme som forretningsrisiko. Det er det ikke. En kritisk sårbarhet på et isolert eller kompenserende kontrollert asset kan bety mindre i praksis enn en lavere-vurdert sak som sitter på et høyt eksponert system koblet til en kritisk forretningsprosess.

Det andre risikoen jeg ser, er tap av kontekst. Automatiserte programmer er bare så gode som assetdata, eierskapsdata, avhengighetskartlegging og unntakshåndtering bak dem. Hvis denne informasjonen er ufullstendig, og i de fleste bedrifter er den det, så kan automatiseringen bli svært effektiv til å flytte feil beslutninger gjennom systemet.

Det tredje risikoen er atferdsmessig. Når mennesker begynner å stole for mye på arbeidsflyten, slutter de å undersøke utgangene. Team antar at det som stiger til toppen, må være det som betyr mest, og det som ikke stiger til toppen, kan vente. Dette er forståelig, men jeg tror det er farlig. For det skifter kulturen fra informert risikostyring til passiv aksept av maskin-drevet orden.

Og så er det en bredere strategisk risiko, som er at organisasjoner begynner å forveksle gjennomstrømming med sikkerhetsforbedring. Å lukke en høy volum av sårbarheter ser operasjonelt bra ut. Det skaper dashboards, metrikker og en følelse av fremdrift. Men hvis du ikke reduserer eksponeringene som betyr mest for forretningsområdet, kan du bare bli raskere til å se busy ut.

Så, min mening er at automatisering absolutt bør gjøre det tungt arbeidet. Men det bør støtte dømmekraft, ikke erstatte det. Ellers ender du opp med en prosess som er effektiv, målbar og skalerbar, men ikke nødvendigvis tryggere.

Du har arbeidet omfattende i IT-transformasjon og enterprise-arkitektur. Hvordan bør CISO-er balansere behovet for å fikse sårbarheter raskt mot de operative risikoene med å forstyrre kritiske forretningsystemer?

Flott spørsmål, for dette er ett av områdene hvor det enkle svaret vanligvis er feil.

Selvfølgelig ønsker du å fikse raskt. Ingen CISO vil argumentere for å sitte på kjente sårbarheter lengre enn nødvendig. Men i en virkelig bedrift, spesielt en som kjører kritiske systemer, er hastighet alene ikke målet. Hvis du fikser dårlig og tar ned noe forretningsområdet avhenger av, har du løst ett problem ved å skape et annet.

Så, balansen er virkelig om å forstå hvilke risikoer som er aktive, hvilke er teoretiske og hvilke systemer kan tåle endring uten å forårsake problemer et annet sted.

Noen sårbarheter trenger virkelig øyeblikkelig handling. Hvis noe er utsatt, utnyttbart og sitter i en del av eiendommen som betyr noe, så handler du. Men mye av tiden er beslutningen mindre absolut enn folk gjør det til. Du kan ha andre kontroller rundt problemet. Det berørte systemet kan være tett innkapslet. Den operative risikoen for å gjøre endringen nå kan være høyere enn å holde stillingen i en kort periode og gjøre det ordentlig.

Dette er hvorfor de bedre CISO-ene tenderer til å være de som kan ha en voksen samtale med forretningsområdet. Ikke bare “Dette er kritisk, fikse det nå”, men “Her er eksponeringen, her er hva som kan skje, her er hva som kan gå galt hvis vi griper feil inn og her er den tryggeste måten å gå frem”. Dette er en mer troverdig form for lederskap enn å behandle hver sårbarhet som om den eksisterer i isolasjon.

Jeg tror også at disse øyeblikkene avslører noe dypere om eiendommen selv. Hvis en organisasjon er konstant redd for å fikse kritiske systemer fordi noen endring føles farlig, så forteller det vanligvis at miljøet har blitt skjørt. For mye skjult avhengighet, ikke nok test-tillit, for lite resilient arkitektur. I en slik situasjon er debatten om fiksing bare et symptom på et mye eldre problem.

Så, ja, fikse raskt der risikoen er virkelig og veien er klar. Men der miljøet er følsomt, er jobben å redusere risiko uten å skape en større rot. Dette er balansen.

Og å være ærlig, de fleste erfarne CISO-er vet allerede dette. Utfordringen er å anvende deres beslutning under press, når klokken tikker og ingen ønsker å eie konsekvensene av å gjøre feil.

Spinnakers tilnærming kombinerer AI-drevet analyse med ekspertvalidering. Hvilke spesifikke oppgaver bør AI håndtere, og hvilke beslutninger bør fortsatt ligge fast i hendene på erfarne sikkerhetseksperter?

Jeg tror skillelinjen er faktisk ganske enkel.

AI bør gjøre arbeidet som drar nytte av hastighet, skala og konsistens. Gå gjennom store mengder data, trekke signaler sammen, spore mønster, høydepunkte ting som ser avvikende ut, hjelpe mennesker med å snevre feltet, dette er nettopp det arbeidet maskiner er nyttige for. Det sparer tid, det reduserer manuelt arbeid og det gir sikkerhetsteam et bedre utgangspunkt.

Det er også godt egnet for de repetitive delene av jobben. Første lag av triage. Sammendrag av funn. Kobling av lignende problemer. Sporing av gjentakende unntak. Peke på hvor bestemte typer kontrollsvakheter fortsatt dukker opp. Ingen av disse tingene erstatter ekspertise, men de gjør bedre bruk av den.

Hvor jeg ville være mye mer forsiktig, er når du flytter fra analyse til beslutning.

De viktige kallene bør fortsatt ligge hos erfarne sikkerhetseksperter. Er dette virkelig en alvorlig risiko i dette forretningsområdet eller ser det bare alvorlig ut i abstrakt? Er dette en virkelig kontrollsvakhet eller er det en rotete, men forstått unntak? Hvis vi fikser dette nå, hva annet kan vi forstyrre? Hvis vi venter, hva godtar vi virkelig? Disse er dømmekraftsbeslutninger.

Og det er før du overhodet kommer inn i den mer menneskelige siden av det. Hvorfor skjer dette? Er organisasjonen bevisst å bære denne risikoen eller har den bare sluttet å merke den? Er dette et isolert problem eller et tegn på noe kulturelt underliggende? Den type tolkning betyr fortsatt en del.

Så, jeg ville la AI gjøre sorteringen, klusteringen, første pass, tungt arbeid. Men jeg ville ikke la det bestemme hva forretningsområdet bør bry seg mest om eller hva handling som bør tas uten menneskelig gjennomgang.

For når en beslutning har konsekvenser, enten operasjonelt, finansielt eller reputasjonsmessig, er du ikke bare håndtering informasjon. Du tar en beslutning.

Og i sikkerhet, tror jeg, det fortsatt bør være en person med virkelig intelligens.

Mange organisasjoner fokuserer fortsatt tungt på sårbarhets-tellinger og alvorlighetspoeng. Hvorfor tror du ekte eksponeringsstyring krever en bredere tilnærming som inkluderer kompenserende kontroller, tilgangsrestriksjoner, systemarkitektur og forretningskontekst?

Det krever en bredere tilnærming fordi et tall på egen hånd ikke forteller deg mye om hvor mye trøbbel du virkelig er i.

Alvorlighetspoeng har sin plass. Sårbarhets-tellinger har sin plass. De hjelper deg å størrelse problemet. De hjelper deg å organisere baklogen. Men de er ikke det samme som å forstå eksponering, og det er hvor jeg tror mange organisasjoner fortsatt får det galt.

En sårbarhet kan se alvorlig ut i teorien og likevel være relativt godt innkapslet i praksis. Hvis tilgang til systemet er tett begrenset, hvis det er andre kompenserende kontroller rundt det, hvis det sitter i en del av miljøet som er vanskelig å nå gjennom tilgangsrestriksjoner, så kan den virkelige sannsynligheten for at problemet skal skade, være ganske annerledes enn hva den rene scoren antyder.

Og så får du det motsatte tilfelle, som ofte er det mer interessante. Noe lavere ned på listen kan vise seg å bety mye mer fordi av hvor det sitter. Det berører en kritisk tjeneste. Det er lettere å nå. Det sitter i en del av systemarkitekturen hvor ett kompromiss gir deg rom til å bevege deg. Dette er den typen ting en enkel alvorlighetsrangering ikke vil forklare godt.

Så, når folk snakker om eksponeringsstyring, må det for meg bety mer enn bare å sortere sårbarheter etter poeng og arbeide nedover listen.

Du må vite hva som sitter rundt problemet. Hva kontrollene som allerede er der, er. Hvem kan nå det. Om systemet er isolert eller koblet til noe viktigere. Og hvis det utnyttes, hva skjer virkelig neste.

Ellers ender du opp med å håndtere bildet av risiko i stedet for risikoen selv. Dashbordet forbedres. Billett-tallene beveger seg. Rapporteringen ser bedre ut. Men du er ikke nødvendigvis tryggere.

Jeg tror delvis grunnen til at dette skjer, er at tall er komfortable. De ser objektive ut. De gir folk noe pent å presentere. De skaper inntrykket av at problemet er redusert til noe målbart og under kontroll. Men virkelig eksponering er vanligvis mye mer rotete enn det.

Det sitter i overlappet mellom svakheten, kontrollene rundt det, arkitekturen det bor i, og forretningskonsekvensen hvis noe går galt.

Så, ja, bruk poengene. Bruk tellinger. Selvfølgelig. Men ikke forveksle dem med forståelse.

Hvis du vil vite hvor den virkelige eksponeringen er, tror jeg du må se på hele miljøet, ikke bare et tall festet til det.

Enterprise-programvare-miljøer går inn i en periode med betydelig endring mens organisasjoner moderniserer legacy-systemer samtidig som de adopterer AI-teknologier. Ser du fremover de neste tre til fem årene, hvordan ser du forholdet mellom AI, sikkerhet og enterprise-plattformer utvikle seg, og hva bør teknologiledere forberede seg på i dag?

Jeg tror de neste tre til fem årene kommer til å være ganske avgjørende.

Hovedsakelig fordi bedrifter prøver å modernisere gamle enterprise-estater samtidig som de bringer AI inn i bildet, og ingen av disse tingene er enkelt på egen hånd. Å gjøre begge sammen øker spillene.

Hva som endrer seg først, tror jeg, er at AI slutter å være en side-eksperiment og begynner å bli en del av hvordan forretningsområdet virkelig fungerer. Det viser seg i arbeidsflyter, støtte, utvikling, sikkerhetsoperasjoner og plattform-administrasjon, ikke som en nysgjerrighet, men som en del av røret.

Og en gang det skjer, blir sikkerhetssamtalen mer alvorlig. Du er ikke bare spørrende om verktøyet er nyttig. Du spør om hva det kan nå, hva det kan påvirke, hva data det matet med er og hva konsekvensene er hvis det får noe galt.

Jeg tror også at vi kommer til å se sikkerhet og arkitektur bli enda vanskeligere å skille. I mange eldre miljøer er det som ser ut som et sikkerhetsproblem, ofte virkelig et arkitekturproblem som bærer et sikkerhetsmerke. Svak identitetsdesign, for mange avhengigheter, uklart eierskap, skjøre integrasjoner, dårlig synlighet, disse er tingene som vanligvis ligger under det synlige problemet. AI vil ikke glatte det bort. Hvis noe, kan det avsløre rotten raskere.

Så, organisasjonene som håndterer dette godt, tror jeg, vil være de som slutter å behandle AI-adopterings-, sikkerhets- og plattform-modernisering som tre separate arbeidsstrømmer. De er stadig mer den samme samtalen.

Hvis jeg skulle rådgive teknologiledere nå, ville jeg starte med synlighet. Du må ha en mye klarere hånd på hva du har, hvordan det kobler seg, hvem som har tilgang til hva, hvor sensitiv data flytter og hvor dine virkelige kontrollpunkter er. Uten det, å legge AI på toppen bare øker antall ting du ikke fullt ut forstår.

Neste ting er styring, men ikke den performative typen. Virkelige beslutninger. Hvor kan AI brukes? Hvor må menneskelig gjennomgang forbli på plass? Hvordan sjekkes utgangene? Hva data er utenfor grenser? Hvem eier konsekvensene hvis systemet driver feil handling? Disse spørsmålene må besvares nå, ikke senere.

Og ærlig talt, forenkling betyr mer enn mange ønsker å innrømme. Jo mer sammenfiltret eiendommen er, jo vanskeligere er det å sikre, jo vanskeligere er det å modernisere, og jo vanskeligere er det å bruke AI uten å skape ny usikkerhet.

Så, de bedre organisasjonene vil være de som vet hvordan å kombinere automatisering med dømmekraft. De vil ikke bare konsumere AI-utgang fordi den er rask eller polert. De vil utfordre den. Teste den. Trykke tilbake på den når nødvendig.

Så, ja, over de neste årene tror jeg AI, sikkerhet og enterprise-plattformer vil bli mye tettere bundet sammen.

Og jeg tror ledere som forbereder seg godt, vil være de som forstår at dette ikke bare er en teknologisk skift. Det er en endring i hvordan beslutninger tas, hvordan kontroll utøves, og hvordan resilient organisasjonen virkelig er.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Spinnaker Support.