Teknologileder med mere end 30 års erfaring fortæller, hvordan man går fra AI-siloer til en styret driftsmodel

Prem Kumar A S har mere end 30 års erfaring med at lede IT- og cloudinfrastrukturprojekter. Han fungerer i øjeblikket som VCTO hos The Preminent.

Vi satte os ned med Prem for at forstå, hvordan organisationer kan bevæge sig fra isolerede AI-initiativer til en styret driftsmodel. Her er, hvad han fortalte os.

30+ års erfaring

Jeg har mere end 30 års erfaring med at lede IT- og cloudinfrastrukturprojekter verden over. Jeg arbejder i øjeblikket som VCTO, hvor jeg rådgiver bestyrelser og CXO'er om teknologi, cyberrisiko, modstandsdygtighed, tillid og styring i AI-æraen. Mit fokus er at hjælpe ledelsesteam med at træffe klarere, stærkere og mere fremtidssikre beslutninger.

Ved siden af dette er jeg vært for PREMINENT KONCLAVE af Power of Knowing Forum — en førende ugentlig podcastserie om teknologi, cybersikkerhed, vækst og strategi med mere end 370 ledelsessamtaler og et voksende ekspertøkosystem.

Sådan bevæger man sig fra isolerede AI-initiativer til en styret driftsmodel

Vi gik fra eksperimenter med værktøjer til en styret driftsmodel — specifikt ved at indføre et lag til AI-styring og implementeringsgennemgang, før en AI-understøttet løsning kunne sættes i drift.

Før dette blev AI udforsket isoleret — copiloter, automatiseringspilotprojekter, analyseanvendelser og visse sikkerhedseksperimenter. Problemet var ikke hensigten, men fragmenteringen. Forskellige teams kunne evaluere eller endda implementere AI-understøttede funktioner uden en fælles ramme for dataklassifikation og eksponeringsrisiko, grænser for modelbrug, godkendelser af AI-værktøjer fra tredjeparter, menneskelig gennemgang og ansvarlighed eller måling af forretningsresultater.

Forenklet sagt begyndte AI at trænge ind i miljøet hurtigere, end styringen kunne følge med. Det skaber tre risici for enhver seriøs organisation:

1. Sikkerheds- og privatlivseksponering: følsomme virksomheds- eller kundedata kommer ind i AI-arbejdsgange uden styring
2. Uensartet drift: teams bruger forskellige værktøjer, prompter og processer uden gentagelige standarder
3. Risiko på bestyrelsesniveau uden overblik: brugen af AI vokser, men ledelsen ved ikke, hvor den reelle eksponering eller ROI ligger

Derfor indførte vi en praktisk kontrolmodel for AI, der er knyttet til, hvordan teknologi udvikles, implementeres og styres — ikke som et teoretisk politikdokument, men som en driftsdisciplin. Det omfattede fem konkrete ændringer:

1. AI-anvendelsestilfælde skulle klassificeres før indførelsen. Alle foreslåede AI-anvendelsestilfælde blev kategoriseret som produktivitet med lav risiko, intern beslutningsstøtte, kundevendte eller følsomme/regulerede/forbundet med høj risiko. Det ændrede straks samtalen fra »Kan vi bruge AI?« til »Hvilket niveau af styring kræver dette AI-anvendelsestilfælde?«
2. Implementering af AI fik et obligatorisk kontrolpunkt. Før et AI-baseret værktøj, en automatisering eller en arbejdsgang kunne flyttes til produktion, skulle det gennemgå en kontrol af datasensitivitet, identitets- og adgangskontroller, leverandør-/modelrisiko, håndtering af instruktioner og output, punkter for menneskelig godkendelse, mekanismer til tilbagefald/tilbagerulning samt krav til revisionslogning. Det gjorde AI-implementering til en del af teknologistyringen og ikke blot innovationsskuebrød.
3. Vi adskilte eksperimentering fra produktion. Der blev oprettet en kontrolleret sandkassemodel til AI-eksperimentering. Teams kunne afprøve idéer hurtigt — men produktionsbrug krævede godkendte datasæt, godkendte værktøjer/modeller, definerede ejere, målbare forretningsresultater og risikogodkendelse, hvor det var nødvendigt. Det var et stort kulturelt skifte, fordi det beskyttede innovationen uden at lade eksperimentering stille og roligt blive til en afhængighed for hele virksomheden.
4. Vi indførte regler for »mennesket i løkken« i følsomme arbejdsgange. Vi krævede menneskelig validering før den endelige handling for alle AI-anvendelsestilfælde, der påvirkede kunder, compliance, økonomiske beslutninger, sikkerhedsdrift eller kritisk forretningskommunikation. Det forhindrede den klassiske fejl at betragte AI-genereret output som automatisk troværdigt, blot fordi det var hurtigt.
5. Vi begyndte at måle AI ud fra driftsværdi og ikke begejstring. Alle AI-initiativer skulle besvare: Hvilken manuel indsats reduceres? Hvilke gennemløbstider forbedres? Hvilke risici reduceres? Hvordan forbedres kvaliteten af beslutninger? Hvilken gevinst i form af omkostninger, produktivitet eller modstandsdygtighed forventes? Det flyttede AI fra en samtale om teknologiske tendenser til en samtale om virksomhedens driftsmodel.

Det gav os bedre kontrol uden at dræbe fremdriften. Styring blev ikke længere opfattet som en hindring. Ved at skabe en klar vej — eksperimentér her, udøv styring her, implementér her — kunne teams arbejde hurtigere med mindre forvirring og mindre skjult risiko.

Det reducerede også risikoen ved uautoriseret AI-brug. Vi fik langt bedre synlighed i, hvilke værktøjer der blev brugt, hvilke teams der brugte dem, hvilke data der blev sendt ind i dem, og hvilke anvendelsestilfælde der havde reel forretningsværdi. Det er afgørende, fordi ukontrolleret indførelse af AI hurtigt er ved at blive den nye form for uautoriseret IT.

Sådan implementerer du AI uden at skabe kaos

Her er nogle tips til dig, der er ved at komme i gang — hvis du vil undgå kaos:

1. Begynd med arbejdsgange med høj volumen og lav risiko. Begynd ikke med beslutninger om kernearkitekturen eller autonome ændringer, der er kritiske for produktionen. Start med dokumentation, oprettelse af tests, intern supporttriage, opsummering af logfiler, udarbejdelse af driftsvejledninger eller generering af versionsnoter.
2. Indfør sikkerhedsrammer før skalering. Enhver udrulning af AI i udviklingen bør definere godkendte værktøjer, politik for brug af instruktioner/data, regler for kodegennemgang, krav til sikkerhedsscanning, grænser for menneskelig godkendelse samt logning og revisionsmuligheder.
3. Mål før og efter. Følg gennemløbstid, implementeringsfrekvens, fejl, der slipper igennem, MTTR, andelen af tilbagerulninger, tid brugt på gentagne opgaver samt feedback om udviklernes tilfredshed og produktivitet.
4. Hold mennesker ansvarlige. AI bør understøtte udviklere og ikke erstatte ejerskabet over udviklingen. Modellen kan foreslå. Teamet skal stadig beslutte, validere, sikre og tage ansvar for resultatet.

De bedste tekniske anvendelsestilfælde for AI

Når AI implementeres korrekt, kan det i tekniske arbejdsgange mærkbart forbedre hastighed, synlighed, produktivitet og kvaliteten af beslutninger. Når det implementeres dårligt, kan det forstærke fejl, øge den operationelle risiko og skabe falsk selvtillid i stor skala.

Her er de anvendelsestilfælde og fordele, jeg ser:

Hurtigere gennemløb i udviklingen, når AI bruges til de rigtige opgaver: De største gevinster viser sig typisk i arbejde med lav til middel kompleksitet, såsom generering af standardkode, oprettelse af testcases, udarbejdelse af dokumentation og driftsvejledninger, opsummering af logfiler og hændelsestriage, oprettelse af skabeloner til infrastruktur som kode, klassificering af sager samt forslag til fejlfinding på første niveau. De kvantitative resultater, jeg ser, omfatter:

• 20–40 % reduktion i cyklustiden for gentagelige tekniske opgaver
• 15–30 % forbedring af udviklernes gennemløb for velafgrænsede opgaver
• 25–50 % hurtigere hændelsestriage, når AI opsummerer logfiler, alarmer og sandsynlige grundårsager
• 30–60 % reduktion i dokumentationsarbejdet for SOP'er, driftsvejledninger og vidensartikler

Bedre effektivitet inden for DevOps og platforme: AI er særligt effektiv inden for DevOps/SRE/infrastrukturoperationer, når den bruges som en digital assistent til analyse frem for som en autonom beslutningstager. Eksempelvis bliver logkorrelation på tværs af værktøjer hurtigere, støjende alarmer grupperes og opsummeres, implementeringsnoter og trin til tilbagerulning genereres automatisk, kapacitetsmønstre identificeres tidligere, og gentagne driftskontroller automatiseres. Kvantitative forbedringer omfatter ofte:

• 20–35 % forbedring af MTTR i miljøer med mange hændelser
• 10–25 % færre eskaleringer til erfarne seniorudviklere ved kendte problemmønstre
• 15–20 % bedre succesrate for ændringer, når AI bruges til at håndhæve implementeringstjeklister, udgivelsesnoter og validering af afhængigheder
• Reduceret rutinearbejde for L1/L2-support- og driftsteams, hvilket frigiver seniorudviklere til arkitektur- og robusthedsarbejde

Prem Kumar deler

Når AI implementeres korrekt i tekniske arbejdsgange, kan den mærkbart forbedre hastighed, synlighed, produktivitet og kvaliteten af beslutninger. Når den implementeres dårligt, kan den forstærke fejl, øge den operationelle risiko og skabe falsk tryghed i stor skala.

Forbedret testteknik og kvalitetsdækning: En af de mest praktiske anvendelser er AI-understøttet test. Det omfatter generering af testcases ud fra krav eller brugerhistorier, identifikation af scenarier med kanttilfælde, oprettelse af testdatamønstre og hjælp til, at teams hurtigere kan forbedre deres regressionsdækning. Positive resultater kan se sådan ud:

• 20–35 % hurtigere oprettelse af testcases
• Højere testdækning inden for den samme sprintperiode
• Kortere cyklusser til forberedelse af regressionstest
• Bedre fejldetektering tidligere i livscyklussen, hvis prompter og validering er stærke

Stærkere vidensstyring og introduktion: AI er undervurderet på ét kritisk område: indsamling af erfaringsbaseret viden. I mange udviklingsteams findes en stor del af den operationelle viden i hovedet på nogle få personer. AI hjælper med at omdanne den til søgbare driftsvejledninger, fejlfindingsvejledninger, arkitekturopsummeringer, introduktionsvejledninger og RCA-opsummeringer. Typiske fordele omfatter:

• Hurtigere introduktion af nye udviklere
• Mindre afhængighed af nogle få “helte”
• Bedre vidensoverførsel på tværs af teams
• Mindre tid brugt på at gennemgå gamle sager og tråde i Slack/Teams

For SMV'er i vækst og mellemstore udviklingsorganisationer kan dette være en af anvendelserne med det højeste investeringsafkast, fordi det forbedrer skalerbarheden af den tekniske viden – ikke kun kodeoutputtet.

Ulemperne ved AI

Resultaterne er selvfølgelig ikke alle gode:

• Fejlprocenterne kan stige, hvis AI presses for hurtigt i produktion. Den største fejl, vi ser, er at betragte AI-genereret kode som “udviklerproduktivitet” uden at styrke gennemgang, test og sikkerhedsvalidering.
• Sikkerheds- og efterlevelsesrisikoen stiger uden sikkerhedsforanstaltninger. Dette er en væsentlig bekymring i regulerede eller følsomme miljøer.

• Teams kan blive hurtigere, men mindre eftertænksomme. En subtil ulempe er kognitiv aflastning. AI bør reducere mekanisk arbejde, ikke reducere den tekniske tænkning.
• Cyklustiden forbedres, men leveringskvaliteten gør ikke. Dette er en af de mest almindelige ledelsesfælder: Teams fejrer hurtigere kodeoutput, men ignorerer, om forretningsresultatet blev forbedret. AI-succes kan ikke kun måles på “hvor meget hurtigere udviklere skriver kode”. Den skal måles på tværs af implementeringsfrekvens, fejlrate for ændringer, fejlrate for undslupne fejl, MTTR, sikkerhedsresultater, omkostning pr. udgivelse og sparede udviklertimer sammenholdt med den omarbejdning, der er skabt.

Det, AI aldrig bør røre ved

Dette er områder, hvor AI bør understøtte tænkningen, men aldrig erstatte den ansvarlige menneskelige beslutningstager.

• Accept af risici. Ingen AI bør beslutte, om en sikkerhedsrisiko skal accepteres, om en rettelse skal udskydes, om driften skal fortsætte med et kendt kontrolgab, eller om en udgivelse skal fortsætte med uløste problemer. Den beslutning tilhører den ansvarlige leder, fordi den har økonomiske, juridiske og omdømmemæssige konsekvenser.
• Kriseledelse. Ved et større driftsstop, en cyberhændelse, et databrud eller en eskalering til myndighederne kan AI hjælpe med data og muligheder. Men mennesker skal tage ansvar for kommunikationen til interessenter, dialogen med myndigheder, beslutninger om kundernes tillid, kommunikation til ledelsen og styringen af krisestaben.
• Etik, privatliv og forretningsmæssige afvejninger. AI kan ikke være den endelige instans i spørgsmålet om, hvorvidt brug af data er etisk acceptabel, om en beslutning er fair over for kunder eller medarbejdere, om en overvågnings- eller kontrolforanstaltning står i et rimeligt forhold til formålet, eller om forretningsmæssig bekvemmelighed bør tilsidesætte principper om tillid. Dette er ledelsesbeslutninger.

Hvorfor arkitektur ikke længere kun handler om skalering og ydeevne

AI fik mig til at genoverveje antagelsen om, at arkitektur er noget, man designer én gang og optimerer over tid. Den model fungerede, når systemer ændrede sig gradvist. Den bryder sammen, når AI-agenter, copiloter, automatiseringslag og datapipelines begynder at påvirke adfærden i produktionen dynamisk.

Prem Kumar deler

Arkitektur handler ikke længere kun om skalering og ydeevne. Det handler nu om tilpasningsevne, sporbarhed, robusthed og styring.

I dag skal arkitektur behandles som et levende kontrolsystem, ikke som en fastlagt plan. Det betyder:

• Systemer skal designes til løbende tilpasning.
• Observerbarhed skal række ud over infrastrukturen og omfatte AI-adfærd og beslutningskvalitet.
• Sikkerhed skal bevæge sig fra perimeterforsvar til indlejret tillid, kontrol og robusthed.

Med andre ord handler arkitektur ikke længere kun om skalering og ydeevne. Det handler nu om tilpasningsevne, sporbarhed, robusthed og styring.

Råd til CTO'er

Mit råd til CTO'er er enkelt: Betragt ikke AI som et teknologikapløb alene — betragt det som et øjeblik, der kræver forretningsmæssigt lederskab. Lige nu jagter for mange organisationer AI-pilotprojekter, værktøjer og anvendelsesområder uden først at stille de vigtigste spørgsmål: Hvilket forretningsproblem løser vi? Hvilken risiko introducerer vi? Hvilken kapacitet opbygger vi på lang sigt?

CTO'er skal lede AI-forandringen på fem områder:

1. Tag udgangspunkt i forretningsværdien, ikke AI-hypen. Hvis AI ikke er knyttet til omsætningsvækst, produktivitet, kundeoplevelse, risikoreduktion eller hurtigere eksekvering, bliver det til eksperimenter uden effekt.
2. Byg AI på et stærkt fundament. AI kan ikke kompensere for svag infrastruktur, fragmenterede data, mangelfuld styring eller uklart ejerskab. CTO'er skal først sikre, at organisationen har den rette datadisciplin, cloud-parathed, cybersikkerhedsforanstaltninger og integrationsarkitektur. Uden dette skalerer AI forvirring hurtigere, end det skalerer værdi.
3. Gør cybersikkerhed, privatliv og styring til designprincipper. Det er ikke tidspunktet til at tilføje sikkerhed senere. AI introducerer nye risici — datalækage, misbrug af modeller, bias, hallucinationer, mangler i compliance og uautoriseret brug af AI på tværs af teams. De bedste CTO'er vil indbygge AI-styring, adgangskontroller, databeskyttelse, ansvarlighed for modeller og menneskeligt tilsyn i driftsmodellen fra dag ét.
4. Gentænk teknologilederens rolle. I denne æra er CTO'en ikke længere kun systemernes forvalter. CTO'en skal blive en oversætter mellem forretningsmæssige ambitioner og teknisk virkelighed — og hjælpe bestyrelsen og den øverste ledelse med at forstå, hvad AI reelt kan gøre, hvor det kan fejle, og hvordan det kan implementeres ansvarligt. Det handler lige så meget om uddannelse, prioritering og opbygning af tillid som om arkitektur.
5. Fokuser på understøttelse før automatisering. Den stærkeste AI-strategi er ikke: "Hvordan erstatter vi mennesker?" Den er: "Hvordan gør vi vores medarbejdere hurtigere, skarpere og mere effektive?" AI bør først understøtte teams — forbedre beslutningstagningen, reducere gentaget arbejde, fremskynde analyser og frigøre talent til bidrag med større værdi. Det er her, tilliden opbygges, anvendelsen forbedres, og transformationen bliver bæredygtig.

Følg med

Du kan følge Prems arbejde på LinkedIn. Og tjekke hans podcast, PREMINENT KONCLAVE.

Der kommer flere ekspertinterviews på The CTO Club!