Teknologileder med over 30 års erfaring deler hvordan man går fra AI-siloer til en styrt operativ modell

Prem Kumar A S har over 30 års erfaring med å lede IT- og skyinfrastrukturprosjekter. Han er for tiden VCTO hos The Preminent.

Vi satte oss ned med Prem for å forstå hvordan organisasjoner kan gå fra isolerte AI-initiativer til en styrt driftsmodell. Her er det han fortalte oss.

Over 30 års erfaring

Jeg har over 30 års erfaring med å lede IT- og skyinfrastrukturprosjekter over hele verden. Jeg arbeider for tiden som VCTO, der jeg rådgir styrer og toppledere innen teknologi, cyberrisiko, robusthet, tillit og styring i AI-æraen. Fokuset mitt er å hjelpe lederteam med å ta tydeligere, sterkere og mer fremtidsrettede beslutninger.

Ved siden av dette er jeg vert for PREMINENT KONCLAVE by Power of Knowing Forum — en ukentlig podkastserie som spenner over teknologi, cybersikkerhet, vekst og strategi, med over 370 ledersamtaler og et voksende ekspertnettverk.

Hvordan gå fra isolerte AI-initiativer til en styrt driftsmodell

Vi gikk fra å eksperimentere med verktøy til en styrt driftsmodell — konkret ved å innføre et lag for AI-styring og distribusjonsgjennomgang før noen AI-aktivert løsning kunne settes i drift.

Før dette ble AI utforsket i isolerte deler av organisasjonen — KI-assistenter, automatiseringspiloter, analysebruksområder og enkelte sikkerhetseksperimenter. Problemet var ikke intensjonen, men fragmenteringen. Ulike team kunne evaluere eller til og med ta i bruk AI-aktiverte funksjoner uten et felles rammeverk for dataklassifisering og eksponeringsrisiko, grenser for modellbruk, godkjenning av tredjeparts AI-verktøy, menneskelig gjennomgang og ansvarlighet eller måling av forretningsresultater.

Enkelt sagt begynte AI å finne veien inn i miljøet raskere enn styringen klarte å holde tritt. Det skaper tre risikoer for enhver seriøs organisasjon:

1. Sikkerhets- og personverneksponering: sensitive forretnings- eller kundedata som kommer inn i uforvaltede AI-arbeidsflyter
2. Manglende operasjonell enhetlighet: team som bruker ulike verktøy, ledetekster og prosesser uten repeterbare standarder
3. Risiko på styrenivå uten innsyn: AI-bruken vokser, men ledelsen vet ikke hvor den reelle eksponeringen eller avkastningen ligger

Derfor innførte vi en praktisk kontrollmodell for AI knyttet til hvordan teknologi utvikles, distribueres og styres — ikke som et teoretisk policydokument, men som en operasjonell disiplin. Dette innebar fem konkrete endringer:

1. AI-bruksområder måtte klassifiseres før innføring. Alle foreslåtte AI-bruksområder ble kategorisert som produktivitet med lav risiko, intern beslutningsstøtte, kundevendte eller sensitive/regulerte bruksområder med høy risiko. Dette endret umiddelbart samtalen fra «Kan vi bruke AI?» til «Hvilket styringsnivå krever dette AI-bruksområdet?»
2. Distribusjon av AI fikk et obligatorisk kontrollpunkt. Før et AI-basert verktøy, en automatisering eller en arbeidsflyt kunne settes i produksjon, måtte det gjennomgå en kontroll av datasensitivitet, identitets- og tilgangskontroller, leverandør- og modellrisiko, håndtering av ledetekster og utdata, punkter for menneskelig godkjenning, reserve- og tilbakerullingsmekanismer samt krav til revisjonslogging. Dette gjorde AI-distribusjon til en del av teknologistyringen, ikke bare et skinn av innovasjon.
3. Vi skilte eksperimentering fra produksjon. Det ble opprettet en kontrollert sandkassemodell for AI-eksperimentering. Teamene kunne teste ideer raskt — men bruk i produksjon krevde godkjente datasett, godkjente verktøy/modeller, definerte eiere, målbare forretningsresultater og risikogodkjenning der det var nødvendig. Dette var et stort kulturelt skifte fordi det beskyttet innovasjonen uten å la eksperimentering i det stille utvikle seg til en virksomhetsavhengighet.
4. Vi innførte regler for «menneske-i-løkken» i sensitive arbeidsflyter. Vi krevde menneskelig validering før den endelige handlingen i alle AI-bruksområder som påvirket kunder, etterlevelse, økonomiske beslutninger, sikkerhetsoperasjoner eller kritisk forretningskommunikasjon. Det forhindret den klassiske feilen med å behandle AI-genererte resultater som automatisk pålitelige bare fordi de var raske.
5. Vi begynte å måle AI etter operasjonell verdi, ikke begeistring. Alle AI-initiativer måtte svare på følgende: Hvilken manuell innsats reduseres? Hvilke gjennomløpstider forbedres? Hvilke risikoer reduseres? Hvordan forbedres kvaliteten på beslutningene? Hvilken gevinst i form av kostnader, produktivitet eller robusthet forventes? Dette flyttet AI fra en samtale om teknologitrender til en samtale om virksomhetens driftsmodell.

Dette ga oss bedre kontroll uten å bremse fremdriften. Styring sluttet å bli sett på som en hindring. Ved å skape en tydelig vei — eksperimenter her, styr her, distribuer her — kunne teamene jobbe raskere med mindre forvirring og lavere skjult risiko.

Det reduserte også risikoen for skjult AI. Vi fikk langt bedre oversikt over hvilke verktøy som ble brukt, hvilke team som brukte dem, hvilke data som ble sendt inn i dem, og hvilke bruksområder som hadde reell forretningsverdi. Dette er avgjørende fordi ukontrollert innføring av AI raskt er i ferd med å bli den nye skjulte IT-en.

Slik innfører du AI uten å skape kaos

Her er noen tips til deg som skal begynne — hvis du vil unngå kaos:

1. Begynn med arbeidsflyter med høyt volum og lav risiko. Ikke start med beslutninger om kjernearkitektur eller autonome endringer som er kritiske for produksjonen. Begynn med dokumentasjon, oppretting av tester, intern supporttriage, oppsummering av logger, utarbeiding av driftsprosedyrer eller generering av versjonsmerknader.
2. Etabler sikkerhetsmekanismer før du skalerer. Alle utrullinger av AI i utviklingsarbeidet bør definere godkjente verktøy, retningslinjer for bruk av ledetekster og data, regler for kodegjennomgang, krav til sikkerhetsskanning, grenser for menneskelig godkjenning samt logging og mulighet for revisjon.
3. Mål før og etter. Følg med på gjennomløpstid, distribusjonsfrekvens, feil som slipper gjennom, MTTR, tilbakerullingsrate, tid brukt på repetitive oppgaver og tilbakemeldinger om utviklernes tilfredshet og produktivitet.
4. La mennesker være ansvarlige. AI bør støtte utviklere, ikke erstatte utviklingsansvaret. Modellen kan foreslå. Teamet må fortsatt beslutte, validere, sikre og eie resultatet.

De beste tekniske bruksområdene for AI

Når AI implementeres på en god måte, kan AI i tekniske arbeidsflyter gi betydelige forbedringer i hastighet, oversikt, produktivitet og beslutningskvalitet. Når det implementeres dårlig, kan det forsterke feil, øke operasjonell risiko og skape falsk trygghet i stor skala.

Her er bruksområdene og fordelene jeg ser:

Raskere gjennomføring i utviklingsarbeidet når AI brukes på riktig type arbeid: De største gevinstene kommer vanligvis i arbeid med lav til middels kompleksitet, som generering av standardkode, oppretting av testtilfeller, utarbeiding av dokumentasjon og driftsprosedyrer, oppsummering av logger og hendelsestriage, oppretting av maler for infrastruktur som kode, klassifisering av saker og forslag til førstelinjefeilsøking. Kvantitative resultater jeg ser, omfatter:

• 20–40 % reduksjon i syklustid for repeterbare tekniske oppgaver
• 15–30 % økning i utviklergjennomstrømming for velavgrenset arbeid
• 25–50 % raskere hendelsesanalyse når AI oppsummerer logger, varsler og sannsynlige rotårsaker
• 30–60 % reduksjon i dokumentasjonsarbeid for SOP-er, driftsprosedyrer og kunnskapsartikler

Bedre effektivitet i DevOps og plattformarbeid: AI er spesielt effektivt i DevOps-/SRE-/infrastrukturdrift når det brukes som en medpilot for analyse, snarere enn som en autonom beslutningstaker. For eksempel blir korrelasjon av logger på tvers av verktøy raskere, støyende varsler grupperes og oppsummeres, distribusjonsnotater og trinn for tilbakerulling genereres automatisk, kapasitetsmønstre flagges tidligere, og repeterende driftskontroller automatiseres. Kvantitative forbedringer omfatter ofte:

• 20–35 % forbedring av MTTR i miljøer med mange hendelser
• 10–25 % færre eskaleringer til seniorutviklere for kjente problemmønstre
• 15–20 % bedre endringsfrekvens når AI brukes til å håndheve distribusjonssjekklister, versjonsnotater og validering av avhengigheter
• Redusert rutinearbeid for L1-/L2-støtte- og driftsteam, slik at seniorutviklere får mer tid til arkitektur- og robusthetsarbeid

Prem Kumar deler

Når AI implementeres på en god måte i tekniske arbeidsflyter, kan det gi betydelige forbedringer i hastighet, synlighet, produktivitet og kvaliteten på beslutningene. Når det implementeres dårlig, kan det forsterke feil, øke driftsrisikoen og skape falsk trygghet i stor skala.

Forbedret testutvikling og kvalitetsdekning: Et av de mest praktiske bruksområdene er AI-assistert testing. Det omfatter å generere testtilfeller fra krav eller brukerhistorier, identifisere scenarier for kanttilfeller, opprette mønstre for testdata og hjelpe team med å forbedre regresjonsdekningen raskere. Positive resultater kan se slik ut:

• 20–35 % raskere oppretting av testtilfeller
• Større testdekning innenfor samme sprintperiode
• Kortere sykluser for forberedelse av regresjonstesting
• Bedre feildeteksjon tidligere i livssyklusen dersom ledetekster og validering er gode

Bedre kunnskapsforvaltning og opplæring: AI er undervurdert på ett kritisk område: å fange opp erfaringsbasert kunnskap. I mange utviklingsteam finnes mye av den operative kunnskapen i hodet på noen få personer. AI bidrar til å omdanne dette til søkbare driftsprosedyrer, feilsøkingsveiledninger, arkitekturoppsummeringer, opplæringsveiledninger og RCA-sammendrag. Typiske fordeler omfatter:

• Raskere opplæring av nye utviklere
• Mindre avhengighet av noen få «helter»
• Bedre kunnskapsoverføring på tvers av team
• Mindre tid brukt på å lete gjennom gamle saker og tråder i Slack/Teams

For SMB-er og mellomstore utviklingsorganisasjoner i vekst kan dette være et av bruksområdene med høyest ROI, fordi det forbedrer skalerbarheten til utviklingskunnskapen, ikke bare kodeproduksjonen.

Ulempene ved AI

Resultatene er selvfølgelig ikke bare positive:

• Feilratene kan øke hvis AI tas i produksjon for raskt. Den største feilen vi ser, er å behandle AI-generert kode som «utviklerproduktivitet» uten å styrke gjennomgang, testing og sikkerhetsvalidering.
• Sikkerhets- og samsvarsrisikoen øker uten kontrollmekanismer. Dette er en stor bekymring i regulerte eller sensitive miljøer.

• Team kan bli raskere, men mindre grundige. En subtil ulempe er kognitiv avlastning. AI bør redusere mekanisk arbeid, ikke redusere den tekniske tenkningen.
• Syklustiden blir bedre, men leveransekvaliteten gjør det ikke. Dette er en av de vanligste fellene for ledere: Team feirer raskere kodeproduksjon, men overser om forretningsresultatet faktisk ble bedre. Suksess med AI kan ikke bare måles ut fra «hvor mye raskere utviklerne skriver kode». Den må måles på tvers av distribusjonsfrekvens, feilrate ved endringer, andel feil som slipper gjennom, MTTR, sikkerhetsfunn, kostnad per leveranse og sparte utviklingstimer sammenlignet med mengden omarbeid som skapes.

Hva AI aldri bør røre

Dette er områdene der AI bør støtte vurderingene, men aldri erstatte den ansvarlige menneskelige beslutningstakeren.

• Aksept av risiko. Ingen AI bør avgjøre om en sikkerhetsrisiko skal aksepteres, om en oppdatering skal utsettes, om virksomheten skal operere med et kjent kontrollgap, eller om en utrulling skal fortsette med uløste problemer. Denne beslutningen tilhører den ansvarlige lederen fordi den har økonomiske, juridiske og omdømmemessige konsekvenser.
• Kriseledelse. Ved et større driftsavbrudd, en cyberhendelse, et datainnbrudd eller en regulatorisk eskalering kan AI bidra med data og alternativer. Men mennesker må ha ansvaret for kommunikasjon med interessenter, kontakt med tilsynsmyndigheter, beslutninger som gjelder kundetillit, kommunikasjon fra ledelsen og styringen av kriserommet.
• Etikk, personvern og forretningsmessige avveininger. AI kan ikke være den endelige autoriteten når det gjelder om bruk av data er etisk akseptabel, om en beslutning er rettferdig overfor kunder eller ansatte, om en overvåkings- eller kontrollmekanisme står i et rimelig forhold til formålet, eller om forretningsmessig bekvemmelighet bør gå foran tillitsprinsipper. Dette er lederbeslutninger.

Hvorfor arkitektur ikke lenger bare handler om skala og ytelse

AI tvang meg til å revurdere antakelsen om at arkitektur er noe man utformer én gang og optimaliserer over tid. Denne modellen fungerte da systemer endret seg gradvis. Den bryter sammen når AI-agenter, samtaleassistenter, automatiseringslag og datapipelines begynner å påvirke produksjonsatferd dynamisk.

Prem Kumar deler

Arkitektur handler ikke lenger bare om skala og ytelse. Nå handler det om tilpasningsevne, sporbarhet, robusthet og styring.

I dag må arkitektur behandles som et levende kontrollsystem, ikke som en fast tegning. Det betyr:

• Systemer må utformes for kontinuerlig tilpasning.
• Observerbarheten må strekke seg utover infrastrukturen og omfatte AI-atferd og kvaliteten på beslutningene.
• Sikkerhet må gå fra perimeterforsvar til innebygd tillit, kontroll og robusthet.

Med andre ord handler arkitektur ikke lenger bare om skala og ytelse. Nå handler det om tilpasningsevne, sporbarhet, robusthet og styring.

Råd til CTO-er

Mitt råd til CTO-er er enkelt: Ikke behandle AI som et rent teknologikappløp — behandle det som et øyeblikk for forretningsledelse. Akkurat nå jakter for mange organisasjoner på AI-piloter, verktøy og bruksområder uten først å stille de viktigste spørsmålene: Hvilket forretningsproblem løser vi? Hvilken risiko introduserer vi? Hvilken kapasitet bygger vi for langsiktig bruk?

CTO-er må lede AI-endringer på fem områder:

1. Start med forretningsverdi, ikke AI-hype. Hvis AI ikke er knyttet til inntektsvekst, produktivitet, kundeopplevelse, risikoreduksjon eller gjennomføringstempo, blir det eksperimentering uten effekt.
2. Bygg AI på et solid fundament. AI kan ikke kompensere for svak infrastruktur, fragmenterte data, dårlig styring eller uklart eierskap. CTO-er må først sørge for at organisasjonen har riktig datadisiplin, skyberedskap, cybersikkerhetsrammer og integrasjonsarkitektur. Uten dette skalerer AI forvirring raskere enn det skalerer verdi.
3. Behandle cybersikkerhet, personvern og styring som designprinsipper. Dette er ikke tiden for å legge til sikkerhet i etterkant. AI introduserer nye risikoer — datalekkasje, misbruk av modeller, skjevhet, hallusinasjoner, manglende etterlevelse og uautorisert AI-bruk på tvers av team. De beste CTO-ene vil bygge AI-styring, tilgangskontroller, databeskyttelse, modellansvarlighet og menneskelig tilsyn inn i driftsmodellen fra dag én.
4. Definer teknologilederens rolle på nytt. I denne æraen er CTO-en ikke lenger bare systemenes forvalter. CTO-en må bli en oversetter mellom forretningsambisjoner og teknisk virkelighet — og hjelpe styret og ledergruppen med å forstå hva AI faktisk kan gjøre, hvor det kan svikte, og hvordan det kan tas i bruk på en ansvarlig måte. Dette handler like mye om opplæring, prioritering og å bygge tillit som om arkitektur.
5. Fokuser på å styrke mennesker før automatisering. Den sterkeste AI-strategien er ikke «Hvordan erstatter vi mennesker?» Den er «Hvordan gjør vi menneskene våre raskere, skarpere og mer effektive?» AI bør først styrke teamene — forbedre beslutningstakingen, redusere repetitivt arbeid, fremskynde analyser og frigjøre talent til bidrag med høyere verdi. Det er her tillit bygges, bruken øker og transformasjonen blir bærekraftig.

Følg med

Du kan følge Prem sitt arbeid på LinkedIn. Sjekk også ut podkasten hans, PREMINENT KONCLAVE.

Flere ekspertintervjuer kommer på The CTO Club!