Mark Fetches, CTO hos Spinnaker Support – Intervju-serie

Mark Fetches er Chief Technology Officer for EMEA hos Spinnaker Support, hvor han rådgiver enterprise-organisationer om teknologi-strategi, sikkerhed, cloud, AI og store transformationsinitiativer. Med mere end 30 års erfaring som konsulent og leder i Accenture, Deloitte og PwC, har Mark arbejdet tæt sammen med C-suite-chefer og bestyrelser for at modernisere komplekse enterprise-miljøer og tilpasse teknologi-beslutninger til langsigtede forretningsmål. Med base i Storbritannien specialiserer han sig i at hjælpe organisationer med at navigere i udfordringerne med legacy-teknologi, operativ risiko og digital transformation med praktisk, business-orienteret vejledning.

Spinnaker Support er en førende global leverandør af tredjepartssoftware-support, managed services og sikkerhedsrådgivning for virksomheder, der kører Oracle (ORCL ), SAP, JD Edwards og andre mission-kritiske platforme.

Du har brugt mere end 20 år på at rådgive virksomheder i Accenture, Deloitte og PwC, før du blev CTO hos Spinnaker Support. Hvad er de største misforståelser, chefer har haft om teknologi-risiko, og hvordan har AI ændret disse diskussioner?

Jeg tror, den største misforståelse har altid været, at teknologi-risiko er noget, der kan håndteres som en specialist-sag. Jeg har aldrig rigtig set det på den måde.

De fleste alvorlige risici, jeg har set, kommer fra ledelsesbeslutninger. Hvor meget kompleksitet man tolererer. Hvor afhængig man bliver af gamle platforme eller nøgle-udbydere. Hvor hårdt man presser på for at få fart. Om man virkelig stoler på de data, forretningen kører på. Teknologi er, hvor disse beslutninger viser sig, men det er sjældent, hvor de starter.

Over årene har jeg set mange chefer fokusere på de åbenlyse ting som cyber, compliance og omkostningsreduktion. Disse er virkelige problemer, naturligvis. Men de risici, der tendrer til at tage virksomheder på sengen, er ofte mere stille end det. Det er platformen, alle ved er skrøbelig, men stadig udskyder at erstatte. Det er data-problemet, ingen rigtig ejer. Det er den outsourcede afhængighed, der ser effektiv ud, indtil den bliver en flaskehals. Disse ting kan ligge i baggrunden i årevis og så pludselig blive meget synlige, når noget går galt.

Jeg tror også, der har været en længerevarende vane med at forveksle compliance med resilience. De er ikke det samme. Du kan bestå en revision og stadig være meget mere udsat, end du tror. En checklist fortæller dig ikke, hvordan forretningen vil reagere under pres, hvor hurtigt den kan genoprette sig, eller om ledere virkelig ser problemet klart nok til at handle det.

Hvad AI har ændret, er niveauet af opmærksomhed. Disse diskussioner lå tidligere længere nede i organisationen. Nu er de midt i diskussionerne i bestyrelseslokalerne om vækst, tillid, produktivitet og brand. Dette er en meget god ting. Men det har også introduceret en ny forenkling, som er idéen om, at AI-modellen, der bruges, er risikoen. Det er sjældent mere end det.

Så hvis jeg skal sammenfatte det, ville jeg sige, at teknologi-risiko aldrig rigtig har været om teknologien alene. Det har altid været en refleksion af ledelsesdom. AI har bare gjort det sværere at ignorere.

Sikkerhedsteams har nu adgang til mere sårbarheds-intelligence end nogensinde før, men virksomheder fortsætter med at kæmpe med prioritering. Hvorfor tror du, industrien har et signal-til-støj-problem i stedet for et detections-problem?

Jeg ville sige, at industrien ikke mangler sårbarheds-data. Det er kort på klarhed.

De fleste sikkerhedsteams har allerede mere end nok inputs, scanner-outputs, trusel-intelligence, alvorlighedsscore, patch-råd, udnyttelses-rapportering. Problemet er ikke, om de kan finde svagheder. Det er, om de kan skille de få, der virkelig kan skade forretningen, fra de mange, der er teknisk interessante, men mindre konsekvensfulde.

Dette er, hvorfor jeg ser det som et signal-til-støj-problem. Detection har forbedret sig enormt. Hvad der ikke har holdt trit, er evnen til at anvende kontekst. En sårbarhed bliver kun en reel prioritet, når du forstår, hvor den sidder, hvor udsat den er, hvor kritisk den påvirkede aktiv er, hvad kompenserende kontroller findes, og hvilken forretnings-påvirkning der ville være, hvis den blev udnyttet.

I praksis falder mange organisationer tilbage på de metrikker, der er letteste at producere, som alvorlighedsscore, patch-tællinger og ældnings-rapporter. Disse er nyttige, men de er ikke det samme som menneskelig dom. En højt-scorende problem i et lav-værdi internt system kan være mindre vigtigt end en lavere-scorende svaghed, der sidder på noget kunde-orienteret eller operationelt kritisk.

Så jeg tror ikke, dette er fundamentalt et synligheds-problem. Det er et forretnings-prioriterings-problem, der skal læres af sikkerhedsteams. Vi er blevet meget gode til at generere fund. Vi er stadig mindre konsekvente til at oversætte disse fund til en kort liste over handlinger, som ledelse kan støtte med tillid.

Og fra min synsvinkel er dette den virkelige ændring, industrien stadig skal gøre, en skift fra at måle, hvor meget vi kan opdage, til at beslutte, hvad der virkelig betyder noget i forhold til forretnings-påvirkning.

På bestyrelsesniveau er dette virkelig et spørgsmål om risiko-oversættelse, kan organisationen omdanne teknisk eksponering til et lille antal klare, handlebare forretnings-prioriteter? De, der kan gøre det godt, er de, der bevæger sig fra støj til signal.

Mange cybersikkerheds-udbydere påstår, at AI kan automatisk prioritere sårbarheder og forudsige trusler. Hvor ser du gapet mellem marketing-narrativen og hvad AI realistisk kan levere i dag i enterprise-miljøer?

Jeg tror, den nemmeste måde at sige det på er, at marketingen omkring dette lover en niveau af sikkerhed, der ikke passer med den virkelighed, som virksomheder arbejder i.

Udbydere beskriver ofte AI, som om det kan hæve sig over støjen, tage det hele ind og pålideligt fortælle sikkerhedsteams, hvad der er vigtigst, og hvad der sandsynligvis vil ske herefter. Det er en overbevisende præsentation, fordi hver sikkerhedsleder vil have mindre støj og mere tillid. Men når du kommer ind i en stor organisation, er tingene sjældent så rene, som det løfte kan holde i en så direkte måde.

AI kan absolut hjælpe. Det kan trække mønstre sammen, reducere noget af den manuelle sortering, højlytte anomalier og hjælpe teams med at arbejde igennem mængder af information, der ellers ville være svære at håndtere, og dette har virkelig værdi. Men der er en forskel mellem at hjælpe et team med at arbejde hurtigere og virkelig at vide, med nogen pålidelig præcision, hvad der skal betyde mest i det specifikke miljø.

Dette er, hvor gapet viser sig. De fleste virksomheder er fulde af ujævn kontekst. Aktiv-inventarer er ufuldstændige. Ejerskab er ikke altid klart. Forretnings-kritikalitet skifter. Kontroller varierer fra den ene del af ejendommen til den anden. Datakvalitet er blandet. Hvis den underliggende billed er patchy, så vil AI’s output også være patchy, uanset hvor poleret grænsefladen måtte se ud.

Jeg tror, dette er særligt sandt, når udbydere taler om forudsigelse. Der er en betydelig forskel mellem at sige, “dette mønster ser risikabelt ud,” og at sige, “dette er, hvad der vil ske herefter.” Det første kan være nyttigt. Det sidste er, hvor sproget ofte løber foran virkeligheden.

Så for mig er AI bedst forstået i dag som en forstærker, ikke en autoritet. Det kan hjælpe teams med at sortere, korrelerer og fokusere. Hvad det ikke kan gøre konsekvent, er at erstatte behovet for menneskelig dom, lokal viden og en klar forståelse af, hvad forretningen virkelig bekymrer sig om.

Dette er virkelig skellet. Narrativen lover sikkerhed. Virkeligheden er mere beskeden og mere nyttig end hypen, hvis du er ærlig om det. AI kan forbedre kvaliteten og hastigheden af analyse, men det fjerner ikke rodheten i enterprise-sikkerhedsbeslutninger.

Spinnaker Support arbejder omfattende med Oracle, SAP og JD Edwards-implementeringer. Hvad gør højt tilpassede ERP-miljøer særligt svære for AI-drevne sikkerhedsværktøjer at forstå og vurdere nøjagtigt?

Hvad der gør disse miljøer svære, er, at de efter mange år ophører med at opføre sig som standardsoftware, som AI er blevet trænet på, og i stedet begynder at opføre sig mere som en optegnelse af, hvordan forretningen virkelig fungerer.

Jeg har set, at dette er særligt sandt i højt tilpassede Oracle-, SAP- og JD Edwards-miljøer. På papir kan du stadig se på en kendt platform. I virkeligheden ser du ofte på år med lokale tilpasninger, brugerdefineret kode, arvede integrationer, tilladelsesstrukturer, rapporteringslogik og workaround, der er bygget til meget specifikke operationelle årsager. For et AI-drevet sikkerhedsværktøj kan dette være svært at læse med nogen reel tillid.

Mange af disse værktøjer fungerer bedst, når miljøet er relativt konsistent, og mønstrene er lette at sammenligne. Højt tilpassede ERP-miljøer er sjældent sådan. Logikken er mere sammenfiltret. Dokumentationen er ofte ufuldstændig. Ejerskab kan være spredt over hold. Hvad der ser usædvanligt ud, kan være fuldstændig intentionelt, og hvad der ser rutine ud, kan vise sig at støtte noget virkelig kritisk i finans, leverancekæde eller operationer.

Dette er, hvor sværheden ligger. Værktøjet er ikke bare bedt om at spotte en sårbarhed eller en mis-konfiguration. Det er bedt om at forstå, hvad dette problem betyder i konteksten af en forretnings-proces, en brugerdefineret afhængighed eller en kontrol-struktur, der måske ikke findes andre steder.

Og det er et meget større problem, end marketingen ofte gør det til. AI kan hjælpe med at højlytte mønstre, reducere noget af den manuelle analyse og pege folk i retning af områder, der er værd at kigge nærmere på. Men hvis ejendommen er kun delvist dokumenteret, formet af år med undtagelser og dybt forbundet med, hvordan virksomheden opererer, er der en grænse for, hvor nøjagtigt et automatiseret system kan fortolke det på egen hånd.

Så jeg tror, det virkelige problem er ikke, om AI kan se noget. Det er, om det kan forstå nok af den omgivende kontekst til at dømme det ordentligt. I højt tilpassede ERP-miljøer er det stadig, hvor menneskelig ekspertise gør en forskel.

En af dine nøgleargumenter er, at menneskelig ekspertise ikke er en flaskehals, der skal elimineres, men en essentiel del af sikkerhedsprocessen. Kan du dele eksempler, hvor menneskelig dom har identificeret risici, som et AI-drevet prioriterings-motor sandsynligvis ville have overset?

Ja, absolut. Og for mig er dette, hvor grænserne for automatiseret prioritering bliver meget åbenlyse.

Nogle risici giver kun mening, når du kender miljøet godt nok til at forstå, hvad der ligger bag dataen. Et system kan ikke se særligt vigtigt ud udefra. Sårbarheds-scoren kan være ubemærkelsesværdig. Men nogen, der kender ejendommen, kan vide, at det støtter løn, kvartalsafslutning, en skrøbelig integration eller en forretnings-proces, som virksomheden simpelthen ikke kan afbryde. Signalet i data kan se almindeligt ud. Den virkelige konsekvens er ikke.

Jeg har også set tilfælde, hvor kontroll-billedet ser bedre ud i teorien end i praksis. En AI-motor kan antage, at en risiko er reduceret, fordi segmentation er på plads, eller fordi adgang er begrænset, eller fordi en overvågnings-kontrol findes. Men en person, der er tæt på miljøet, kan vide, at en kontrol er inkonsistent anvendt, en anden er omgået, når operationer er under pres, og en tredje har stoppet med at være pålidelig. Den slags gap viser sig ikke altid rent i systemet af record.

Dette samme sker i tilpassede miljøer. Et script, en workflow eller en tilladelses-model kan se rutine ud, hvis du scannrer efter mønstre i stor målestok. For nogen, der forstår, hvordan systemet er tilpasset over tid, kan detaljen stå ud med det samme som en reel kilde til eksponering.

Tidspunktet betyder også noget. En sårbarhed kan se håndterbar ud i isolation, så bliver det pludselig meget mere alvorligt, fordi forretningen er midt i en migration, en overtagelse, en regulativ deadline eller en peak-operativ periode. Den slags skift er ikke altid let for en automatiseret motor at fortolke med den rette vægt.

Så når jeg taler om menneskelig ekspertise, taler jeg ikke om instinkt i nogen vag forstand. Jeg mener lokal viden. Hukommelse. Dom. Evnen til at se, når et lille teknisk problem er knyttet til noget meget mere konsekvent.

Dette er, hvorfor jeg ikke ser menneskelig ekspertise som en flaskehals, der skal fjernes. Jeg ser det som den del, der forhindrer falsk tillid. AI kan hjælpe med at sortere og snævre dataene. Men de risici, der betyder mest, er ofte de, der kun bliver åbenlyse, når nogen forstår, hvordan forretningen virkelig fungerer.

Da organisationer skynder sig at adoptere AI på tværs af sikkerhedsoperationer, hvad er de største risici ved at over-automatisere sårbarhedsstyring og eksponerings-vurdering?

Den største risiko, jeg ser, er, at du skaber illusionen af kontrol uden virkeligheden af at forstå, at du er i kontrol.

Sårbarhedsstyring er et af disse områder, hvor automation er åbenbart nyttig. I enterprise-mål skal du have automation for at finde problemer, korrelerer data, prioriterer i stor målestok og holde hele processen i gang. Ingen alvorlig organisation kan håndtere det manuelt.

Men farerne kommer, når automation begynder at drive programmet uden nok menneskelig udfordring omkring det.

Det første åbenlyse risiko er falsk prioritering. Hvis du afhænger for meget af automatiseret scoring, kan du ende med at behandle teknisk alvorlighed, som om det var det samme som forretnings-risiko. Det er det ikke. En kritisk sårbarhed på en isoleret eller kompenserende kontrolleret aktiv kan betyde mindre i praksis end en lavere-scorende problem, der sidder på et højt eksponeret system forbundet til en kritisk forretnings-proces.

Det andet risiko, jeg ser, er tab af kontekst. Automatiserede programmer er kun så gode som de data, ejerskab, afhængigheds-kortlægning og undtagelseshåndtering bag dem. Hvis den underliggende information er ufuldstændig, og det er den ofte i de fleste virksomheder, så kan automationen blive meget effektiv til at flytte fejlbeslutninger gennem systemet.

Det tredje risiko er adfærdsmæssigt. Når folk begynder at stole for meget på workflow, stopper de med at udfordre dets outputs. Teams antager, at det, der stiger til toppen, må være, hvad der betyder mest, og det, der ikke stiger til toppen, kan vente. Det er forståeligt, men jeg tror, det er farligt. For det skifter kulturen fra informeret risiko-styring til passiv accept af maskin-drevet prioritering.

Og så er der en bredere strategisk risiko, som er, at organisationer begynder at forveksle gennemstrømning med sikkerhedsforbedring. Lukning af en høj volumen af sårbarheder ser operationelt godt ud. Det skaber dashboards, metrikker og en fornemmelse af momentum. Men hvis du ikke reducerer de eksponeringer, der betyder mest for forretningen, kan du blot blive bedre til at se ud, som om du er travlt optaget.

Så mit synspunkt er, at automation skal absolut gøre det tungt arbejde. Men det skal støtte dom, ikke erstatte det. Ellers ender du med en proces, der er effektiv, målbart og skalerbart, men ikke nødvendigvis sikrere.

Du har arbejdet omfattende med IT-transformation og enterprise-arkitektur. Hvordan bør CISO’er balancere behovet for at lukke sårbarheder hurtigt mod de operationelle risici ved at afbryde kritiske forretnings-systemer?

Godt spørgsmål, for dette er et af disse områder, hvor den lette løsning ofte er den forkerte.

Selvfølgelig vil du lukke sårbarheder hurtigt. Ingen CISO vil argumentere for at sidde på kendte sårbarheder længere, end nødvendigt. Men i en virkelig virksomhed, især en, der kører kritiske systemer, er fart alene ikke målet. Hvis du lukker dårligt og tager noget ned, som forretningen afhænger af, har du løst et problem ved at skabe et andet.

Så balancen er virkelig om at forstå, hvilke risici der er levende, hvilke der er teoretiske, og hvilke systemer kan tolerere ændring uden at skabe problemer andre steder.

Nogle sårbarheder behøver virkelig hurtig handling. Hvis noget er eksponeret, udnytteligt og sidder i en del af ejendommen, der betyder noget, så handler du. Men ofte er beslutningen mindre absolut, end folk gør det til. Du kan have andre kontroller omkring problemet. Det påvirkede system kan være tæt indekapslet. Den operationelle risiko ved at lave ændringen i dag kan være højere end at holde positionen i en kort periode og gøre det ordentligt.

Dette er, hvorfor de bedre CISO’er tenderer til at være dem, der kan have en voksen samtale med forretningen. Ikke bare, “Dette er kritisk, luk det nu,” men “Her er eksponeringen, her er, hvad der kan ske, her er, hvad der kan gå galt, hvis vi griber fejl, og her er den sikreste vej igennem det.” Det er en mere troværdig form for ledelse end at behandle hver sårbarhed, som om den eksisterer i isolation.

Jeg tror også, disse øjeblikke afslører noget dybere om ejendommen selv. Hvis en organisation altid er bange for at lukke kern-systemer, fordi enhver ændring føles farlig, så fortæller det dig noget om, hvor skrøbelig miljøet er blevet. For mange skjulte afhængigheder, ikke nok test-tillid, for lidt resilience i arkitekturen. I den situation er sårbarheds-debatten virkelig et symptom på et meget ældre problem.

Så ja, luk hurtigt, hvor risikoen er reel, og vejen er klar. Men hvor miljøet er følsomt, er jobbet at reducere risiko uden at skabe en større rod. Dette er balancen.

Og for at være ærlig, de fleste erfarne CISO’er ved allerede dette. Udfordringen er at anvende deres beslutning under pres, når uret tikker, og ingen vil eje konsekvenserne af at gøre det forkert.

Spinnakers tilgang kombinerer AI-drevet analyse med ekspert-validering. Hvordan bør AI håndtere specifikke opgaver, og hvilke beslutninger bør forblive fast i hænderne på erfarne sikkerhedsprofessionelle?

Jeg tror, skillelinjen er faktisk ret enkel.

AI bør gøre det arbejde, der drager fordel af fart, skala og konsistens. Gennemgang af store mængder data, trække mønstre sammen, spotte ting, der ser forkerte ud, hjælpe folk med at snævre feltet, dette er præcis det arbejde, maskiner er nyttige til. Det sparer tid, det reducerer manuelt arbejde, og det giver sikkerhedsteams en bedre startposition.

Det er også velegnet til de repetitive dele af jobbet. Første lag af triage. Sammendrag af fund. Forbindelse af lignende problemer. Sporing af gentagne undtagelser. Peger på, hvor bestemte typer af kontrol-svaghed fortsætter med at dukke op. Ingen af disse ting erstatter ekspertise, men de gør bedre brug af den.

Hvor jeg ville være mere forsigtig, er, når du bevæger dig fra analyse til beslutning.

De vigtige kald bør stadig sidde hos erfarne sikkerhedsprofessionelle. Er dette virkelig et alvorligt risiko i denne forretning, eller ser det bare alvorligt ud i abstrakt? Er dette en ægte kontrol-fejl eller er det en rod, men forstået undtagelse? Hvis vi løser dette nu, hvad andre problemer kan vi skabe? Hvis vi venter, hvad accepterer vi virkelig? Disse er doms-kald.

Og det er før, du overhovedet kommer til den mere menneskelige side af det. Hvorfor sker dette? Er organisationen bevidst om at bære denne risiko, eller har den bare stoppet med at bemærke det? Er dette et isoleret problem eller et tegn på noget kulturelt underliggende? Den slags fortolkning betyder stadig en del.

Så jeg ville lade AI gøre sorteringen, klusteringen, første gennemgang, det tungt arbejde. Men jeg ville ikke lade det beslutte, hvad forretningen skal bekymre sig mest om, eller hvilken handling der skal tages uden menneskelig gennemgang.

For når en beslutning har konsekvenser, enten operationelt, finansielt eller reputations-mæssigt, er du ikke længere bare bearbejder information. Du tager en dom.

Og i sikkerhed, tror jeg, det stadig skal være en person med virkelig intelligens.

Mange organisationer fokuserer stadig stærkt på sårbarheds-tællinger og alvorligheds-score. Hvorfor tror du, at ægte eksponerings-styring kræver en bredere synsvinkel, der inkluderer kompenserende kontroller, adgangs-begrænsninger, system-arkitektur og forretnings-kontekst?

Det kræver en bredere synsvinkel, fordi et tal alene ikke fortæller dig meget om, hvor meget problemer du virkelig er i.

Alvorligheds-score har sin plads. Sårbarheds-tællinger har deres plads. De hjælper dig med at størrelse-problemet. De hjælper dig med at organisere baglogen. Men de er ikke det samme som at forstå eksponering, og det er, hvor jeg tror, mange organisationer stadig får det forkert.

En sårbarhed kan se alvorlig ud i teorien og stadig være relativt vel indekapslet i praksis. Hvis adgang til systemet er tæt begrænset, hvis der er andre kompenserende kontroller omkring det, hvis det sidder i en del af miljøet, der er svær at nå gennem adgangs-begrænsninger, så kan den virkelige sandsynlighed for, at dette problem skaber skade, være meget forskellig fra, hvad den rene score antyder.

Og så får du den modsatte sag, som ofte er den mere interessante. Noget lavere på listen kan vise sig at betyde meget mere, fordi det sidder på noget kritisk. Det rører en kritisk service. Det er lettere at nå. Det sidder i en del af system-arkitekturen, hvor en kompromis giver dig plads til at bevæge dig. Det er den slags, en simpel alvorligheds-rangering ikke kan forklare godt.

Så når folk taler om eksponerings-styring, må det for mig betyde mere end bare at rangere sårbarheder efter score og arbejde ned ad listen.

Du behøver at vide, hvad der sidder omkring problemet. Hvad kontrollerne er. Hvem kan nå det. Om systemet er isoleret eller forbundet til noget mere vigtigt. Og hvis det udnyttes, hvad sker der virkelig herefter.

Ellers ender du med at styre billedet af risiko i stedet for risikoen selv. Dashboardet forbedres. Billet-numre flytter sig. Rapporteringen ser bedre ud. Men du er ikke nødvendigvis sikrere.

Jeg tror, en del af årsagen til, at dette sker, er, at tal er beroligende. De ser objektive ud. De giver folk noget pænt at præsentere. De skaber en fornemmelse af, at problemet er reduceret til noget målbart og under kontrol. Men virkelig eksponering er ofte meget mere rodende end det.

Den ligger i overlappet mellem svagheden, kontrollerne omkring det, arkitekturen det bor i, og forretnings-konsekvensen, hvis noget går galt.

Så ja, brug scorene. Brug tællingerne. Naturligvis. Men forveksl dem ikke med forståelse.

Hvis du vil vide, hvor den virkelige eksponering er, tror jeg, du må se på hele miljøet, ikke kun et tal, der er knyttet til det.

Enterprise-software-miljøer går ind i en periode med betydelig forandring, da organisationer moderniserer legacy-systemer samtidig med, at de adopterer AI-teknologier. Ser du fremover over de næste tre til fem år, hvordan vil forholdet mellem AI, cybersikkerhed og enterprise-platforme udvikle sig, og hvad bør teknologi-ledere forberede sig på i dag?

Jeg tror, de næste tre til fem år vil være ret definerende.

Primært fordi virksomheder forsøger at modernisere gamle enterprise-ejendomme på samme tid, som de bringer AI ind i billedet, og ingen af disse ting er lette på egen hånd. At gøre begge dele samtidig øger spillet.

Hvad der ændrer sig først, tror jeg, er, at AI stopper med at være en side-eksperiment og begynder at blive en del af, hvordan forretningen faktisk kører. Det viser sig i workflows, support, udvikling, sikkerhedsoperationer og platform-administration, ikke som en nysgerrighed, men som en del af røret.

Og når det sker, bliver cybersikkerheds-samtalen mere alvorlig. Du er ikke bare spurgende, om værktøjet er nyttigt. Du er spurgende, hvad det kan nå, hvad det kan påvirke, hvilke data det føder på, og hvilke konsekvenser der er, når det får noget forkert.

Jeg tror også, vi vil se, at sikkerhed og arkitektur bliver endnu sværere at adskille. I mange ældre miljøer er det, der ser ud som et sikkerhedsproblem, ofte i virkeligheden et arkitektur-problem, der bærer et sikkerheds-mærke. Svag identitets-design, for mange afhængigheder, uklar ejerskab, skrøbelige integrationer, dårlig synlighed, disse er de ting, der tenderer til at ligge under det synlige problem. AI vil ikke glatte det ud. Hvis noget, kan det afsløre rodningen hurtigere.

Så organisationerne, der håndterer dette godt, tror jeg, vil være dem, der stopper med at behandle AI-adopterings-, cybersikkerheds- og platform-moderniserings-arbejdet som tre separate arbejdsstrømme. De er mere og mere den samme samtale.

Hvis jeg skulle rådgive teknologi-ledere nu, ville jeg starte med synlighed. Du behøver en meget klarere forståelse af, hvad du har, hvordan det forbinder, hvem der har adgang til hvad, hvor følsomme data flytter, og hvor dine virkelige kontrol-punkter er. Uden det bliver lagning af AI på toppen kun en øget mængde af ting, du ikke fuldstændig forstår.

Derefter er det governance, men ikke den performative slags. Ægte beslutninger. Hvor kan AI bruges? Hvor skal menneskelig gennemgang blive? Hvordan tjekkes outputs? Hvad data er udenfor grænser? Hvem ejer konsekvenserne, hvis systemet driver den forkerte handling? Disse spørgsmål skal besvares nu, ikke senere.

Og ærligt, simplificering betyder mere, end mange vil indrømme. Jo mere sammenfiltret ejendommen er, jo sværere er det at sikre, jo sværere er det at modernisere, og jo sværere er det at bruge AI uden at skabe ny usikkerhed.

Så de bedre organisationer vil være dem, der ved, hvordan man kombinerer automation med dom. De vil ikke bare forbruge AI-output, fordi det er hurtigt eller poleret. De vil udfordre det. Teste det. Presse tilbage på det, når det er nødvendigt.

Så ja, over de næste få år tror jeg, AI, cybersikkerhed og enterprise-platforme vil blive meget tættere forbundet.

Og jeg tror, at de ledere, der forbereder sig godt, vil være dem, der forstår, at dette ikke kun er en teknologi-skift. Det er en ændring i, hvordan beslutninger tages, hvordan kontrol udøves, og hvordan robustheden i organisationen virkelig er.

Thank you for the great interview, readers who wish to learn more should visit Spinnaker Support.