Global felt-CTO oppfordrer ledere til å prioritere datainfrastruktur før KI

Kai Waehner er global felt-CTO i Confluent og har rådgitt store virksomheter som BMW og Siemens. Han fokuserer på datainfrastruktur, integrasjonsstrategi og innføring av AI.

Vi tok en prat med Kai for å forstå hvorfor så mange AI-initiativer i store virksomheter mislykkes. Her er det han hadde å si.

En fordel gjennom mønstergjenkjenning

Jeg heter Kai Waehner. De siste ni årene har jeg vært global felt-CTO i Confluent, og jeg har jobbet med hundrevis av virksomheter i Nord-Amerika, Europa og Asia-Stillehavsregionen. Jeg har rådgitt selskaper som BMW, Volkswagen, Lufthansa, Siemens, DISH Networks og Globe Telecom. Jeg jobber med ledere innen teknologistrategi, gjennomføring av markedsstrategier, leverandørvurdering, virksomhetsarkitektur og innholdsproduksjon.

Rollen som felt-CTO skiller seg fra å lede én enkelt utviklingsorganisasjon. Jeg jobber samtidig på tvers av dusinvis av kundemiljøer og rådgir arkitekter og ledere på toppnivå om datainfrastruktur, integrasjonsstrategi og innføring av AI. Denne bredden gir meg en fordel gjennom mønstergjenkjenning som er vanskelig å oppnå internt i ett enkelt selskap.

Bakgrunnen min dekker hele historien til dataintegrasjon i store virksomheter: ETL, ESB, iPaaS og API-administrasjon, deretter ni år med fokus på datastrømming med Apache Kafka og Flink som grunnmuren for hendelsesdrevne arkitekturer, og i økende grad prosessorkestrering og AI på hele spekteret fra prediktiv maskinlæring til generativ og agentbasert AI. Jeg orienterer jevnlig analytikere hos Gartner og Forrester og publiserer min egen forskning, som dekker leverandørlandskap, arkitekturmønstre og praktiske bransjecase-studier. Jeg har også utgitt en bok om datastrømming.

Samtalen om AI-transformasjon som jeg har med teknologiledere, handler først og fremst ikke om modeller. Den handler om infrastrukturen under dem. Agentbaserte AI-systemer som utfører autonome handlinger i arbeidsflyter i virksomheten, trenger tre ting for å fungere pålitelig:

• Sanntidsdata, slik at de handler ut fra dagens virkelighet
• Prosessintelligens som definerer hva de har lov til å gjøre
• Tillit som er bygget inn i arkitekturen, ikke bare i modellen

Det er denne konvergensen tankegangen min fokuserer på.

Hvorfor arkitekturlagene må samles for å lykkes med AI

På tvers av bransjer ser jeg konsekvent at virksomheter investerer tungt i tre separate lag: en grunnmur for dataintegrasjon, et lag for prosessautomatisering og, i økende grad, et AI-initiativ. Problemet er at disse tre nesten aldri utformes for å fungere sammen. Dataintegrasjon flytter data, men kobler seg ikke til forretningsbeslutninger. Prosessautomatisering håndhever arbeidsflyter, men kjører på utdatert kontekst. AI-agenter genererer anbefalinger eller utfører handlinger, men mangler en styrt avgrensning rundt hva de kan gjøre. Hvert lag fungerer isolert. Den samlede arkitekturen mangler.

Distribusjonsmodellene jeg ser, varierer betydelig. Noen organisasjoner kjører fullstendig administrert, skybasert infrastruktur på AWS, Azure eller GCP, og større globale virksomheter inkluderer ofte distribusjoner på fastlands-Kina på Alibaba Cloud, som holdes bevisst atskilt av juridiske, regulatoriske og personvernmessige hensyn. Andre bruker hybride arkitekturer med datasentre lokalt koblet til skyen, drevet av krav til datasuverenitet eller eldre systemer som de ikke kan flytte raskt. Regulerte bransjer som finansielle tjenester og helsetjenester har nesten alltid krav om flere regioner eller flere skyer, ikke etter eget valg, men på grunn av lovpålagte krav til etterlevelse. Produksjonskunder har ofte distribusjoner på kanten, der de behandler data nær fabrikkgulvet før de samler dem sentralt.

På tvers av alle disse miljøene har hendelsesdrevet arkitektur blitt virksomhetskritisk infrastruktur. Apache Kafka har etablert seg som den faktiske standarden for hendelsesmeglere som muliggjør reell frakobling mellom systemer, sanntidsbehandling i alle størrelsesordener samt hybrid integrasjon og integrasjon på tvers av flere skyer. PayPal behandler over én billion Kafka-meldinger daglig. New Relic tar inn milliarder av datapunkter per minutt. Dette er ikke eksperimentelle distribusjoner. De er virksomhetens operative grunnmur.

Mange virksomheter har allerede de tre delene de trenger for pålitelig agentbasert AI. Det de mangler, er en arkitektonisk forpliktelse til å samle dem.

Hvorfor datagrunnlaget må være på plass før AI-beredskapen

Kais tanker

AI-beredskap er dataforberedelse.

Dette er det jeg har funnet: AI er ikke den vanskelige delen. Det er datainfrastrukturen under den.

De fleste AI-initiativer i store virksomheter som jeg har sett lykkes eller mislykkes de siste ni årene, har i mindre grad vært avhengige av hvilken modell som ble valgt, og i større grad av hvorvidt organisasjonen hadde et pålitelig, styrt sanntidsgrunnlag som kunne forsyne modellen med oppdaterte, nøyaktige og pålitelige data.

En godt tilpasset modell som mottar utdaterte eller inkonsistente data, vil produsere upålitelige resultater. Et agentisk AI-system uten et prosesslag som definerer hva det kan gjøre, vil før eller siden utføre en handling ingen kan forklare eller reversere. Dette er ikke modellproblemer. Det er infrastruktur- og arkitekturproblemer. Og de er fullt ut forutsigbare før man skriver én eneste linje med AI-kode.

Den praktiske konsekvensen er at AI-beredskap er databeredskap. Før man velger en modell, før man velger en AI-leverandør, før man lanserer et pilotprosjekt, bør en CTO kunne svare ærlig på tre spørsmål.

1. Har organisasjonen pålitelig tilgang til sanntidsdata fra de operative systemene?
2. Finnes det styrte prosesser som definerer hva et AI-system kan og ikke kan gjøre autonomt?
3. Finnes det et rammeverk for tillit på arkitekturnivå, ikke bare inne i modellen, som kan håndheve disse grensene i produksjon?

Hvis svaret på noen av disse tre spørsmålene er nei, bør AI-reisen begynne der, ikke med modellen.

Hvorfor AI må bygges inn i eksisterende forretningsprosesser

Den viktigste endringen jeg har drevet frem, er å gå fra å bygge AI som et separat initiativ til å bygge det inn i eksisterende forretningsprosesser. Dette får altfor lite oppmerksomhet, til tross for konsekvensene. Faktisk vil jeg si at de fleste CTO-er bør gå fra å utforme nye AI-systemer til å utforme hvordan AI deltar i eksisterende arbeidsflyter, hvilke grenser prosesslaget håndhever, og hvordan styring og etterprøvbarhet bygges inn – før én eneste modell settes i drift.

Før jeg gjorde denne endringen, var mønsteret nesten alltid det samme. Et AI-prosjekt startet frakoblet fra de operative systemene. Modellen presterte godt i laboratoriet. I produksjon manglet den pålitelig tilgang til oppdaterte data, en tydelig grense for handlingene sine og integrasjon med godkjenningsflytene virksomheten var avhengig av. Imponerende demonstrasjon. Mislykket utrulling.

Endringen jeg nå konsekvent arbeider for, består av to deler.

• For det første må den eksisterende hendelsesdrevne arkitekturen behandles som grunnlaget for AI-adopsjon, ikke som noe som skal erstattes. Systemene består. Forretningsprosessene består. AI deltar i arbeidsflyter som allerede kjører, bruker sanntidshendelser og handler innenfor grenser som defineres av prosesslaget.
• For det andre må AI-sikkerhetsmekanismene flyttes ut av modellen og inn i laget for prosessorkestrering. En godt tilpasset modell er ikke nok. Pålitelig AI i produksjon innebærer at arbeidsflytlaget håndhever godkjenningspunkter, eskaleringsbaner og revisjonsspor for hver autonome handling agenten utfører.

Alpian, Sveits’ første fullt lisensierte digitale privatbank, er et godt eksempel på at dette gjøres riktig fra dag én. Alpian bygde hele plattformen sin hendelsesdrevet, med Apache Kafka som sentralnervesystemet som kobler sammen mikrotjenester, domenedataprodukter og AI-agenter. Da de introduserte agentisk AI og RAG i arbeidsflyter for kundeinteraksjon, var arkitekturen allerede klar. Kafka-hendelser ga agentene kontekst i sanntid. Prosesslaget håndhevet samsvarskontroller. De bygde inn kryptering på feltnivå og skjemastyring fra starten.

Resultatet var en regulert finansinstitusjon som kjørte autonome AI-agenter i styrte og etterprøvbare arbeidsflyter – nøyaktig det mønsteret de fleste tradisjonelle virksomheter nå forsøker å ettermontere.

Organisasjoner som lykkes med dette, behandler AI-adopsjon som en arkitekturfaglig disiplin, ikke som en prosjektsprint.

Hvorfor databeredskap avgjør om AI-utrullingen lykkes

Etter ni år i Confluent på tvers av hundrevis av virksomhetsmiljøer har jeg sett svært ujevne resultater med AI. Forskjellen mellom gode og dårlige resultater skyldes nesten alltid én ting: om datainfrastrukturen var klar før AI ble introdusert.

På den positive siden er tallene fra godt utformede implementeringer overbevisende. BMW forhindrer over 500 minutter med uplanlagt produksjonsstans per år ved ett enkelt anlegg. Alpian driver en fullt regulert digital bank med agentisk KI integrert i styrte, reviderbare klientarbeidsflyter. Det kvalitative mønsteret på tvers av vellykkede implementeringer er konsistent: raskere tid til markedet, reduserte driftskostnader i arbeidsflyter med stort volum og mange gjentakelser, samt en merkbart bedre kundeopplevelse når KI får tilgang til sanntidskontekst i stedet for utdaterte batchdata.

På den negative siden er feilsmønsteret like konsistent. KI-prosjekter uten et styrt datafundament gir nesten alltid samme resultat: imponerende demonstrasjoner, mislykkede produksjonsimplementeringer. Modellen fungerer i laboratoriet. I produksjon mottar den utdaterte eller inkonsistente data, hallusinerer i kanttilfeller, utfører handlinger uten revisjonsspor og svekker i stedet for å bygge virksomhetens tillit til KI. MIT-forskning anslår at rundt 95 % av KI-piloter i virksomheter ikke leverer målbar forretningsverdi. Dette tallet samsvarer med mine observasjoner fra feltet.

Den nyeste feilmodusen jeg ser, er styring som innføres for sent. Organisasjoner implementerer agentisk KI og oppdager deretter, vanligvis etter en hendelse, at ingen prosesslag har definert hva agenten kan gjøre, at det ikke finnes noen eskaleringsvei for usikre modellresultater, og at det mangler et revisjonsspor for å rekonstruere hendelsesforløpet. Dette er ikke et KI-problem. Det er et arkitekturproblem. Og det kan i sin helhet forebygges.

Hvorfor KI informerer beslutninger, men mennesker sikrer ansvarlighet

Jeg ser konsekvent et mønster: KI informerer og akselererer. Den tar selvstendige beslutninger innenfor definerte grenser. Men mennesker har ansvaret for de beslutningene som betyr mest.

På den KI-informerte siden gir forskningssyntese, innholdsproduksjon, kodegenerering for velavgrensede problemer, automatisert testing og sikkerhetsskanning tydelig verdi. I mitt eget arbeid komprimerer KI-verktøy flere dagers syntese av analyserapporter, kundesamtaler og teknisk dokumentasjon. Resultatet krever fortsatt ekspertvurdering for å valideres, men utgangspunktet ligger langt lenger fremme.

Når det gjelder selvstendige beslutninger, bør KI-agenter beslutte uavhengig når risikoen er avgrenset og prosessen er godt styrt. Svindeloppdagelse i finansielle tjenester er det tydeligste eksempelet. Under en definert risikoterskel blokkerer en KI-agent automatisk en transaksjon uten at et menneske er involvert. Når transaksjonsbeløpet øker og den regulatoriske eksponeringen blir større, sender prosessorkestreringslaget saken til en menneskelig analytiker før det iverksetter tiltak. Grensen er ikke fast. Virksomheten definerer den, arbeidsflyten koder den, og prosesslaget håndhever den – ikke modellen selv.

På den eksplisitt menneskelige siden trekker jeg grensen ved beslutninger med store arkitektoniske konsekvenser, strategisk forretningsrisiko eller betydelig regulatorisk ansvar. Valg av et grunnleggende arkitekturmønster, valg av en strategisk teknologileverandør og utforming av styringsmodellen for et agentisk KI-system er fortsatt menneskelige beslutninger. Det å bevege seg raskere opphever ikke konsekvensene av å ta feil.

Hvorfor KI leverer svakere resultater på tre hovedområder

KI har ikke levert den tekniske eller teknologiske effekten kundene opprinnelig forventet på tre områder.

Det første er integrasjon av virksomhetsdata. KI lovet å gjøre det dramatisk enklere å koble sammen heterogene systemer: skjemakartlegging, håndheving av datakvalitet, transformasjonslogikk og styring på tvers av komplekse hybride miljøer. I praksis bistår KI med disse oppgavene, men løser dem ikke. En modell kan ikke resonnerere seg ut av den underliggende arkitekturgjelden, eldre systemer med udokumenterte datamodeller, inkonsistent semantikk på tvers av forretningsenheter, manglende metadata og fragmentert eierskap. Ingeniørene må fortsatt gjøre det krevende arbeidet.

Det andre er agentisk KI i komplekse virksomhetsarbeidsflyter med flere trinn. Demonstrasjonene er overbevisende. I produksjon feiler agenter uforutsigbart når de møter kanttilfeller som treningsdataene ikke dekket, når kontekstvinduet mangler tilstrekkelig aktuell tilstand, eller når prosesslaget ikke fanger opp og håndterer agentfeil på en god måte. Avstanden mellom det en agent kan gjøre i et kontrollert miljø, og det vi kan stole på at den gjør autonomt i en regulert produksjonsarbeidsflyt, er fortsatt betydelig.

Det tredje er arkitektonisk beslutningstaking. KI-verktøy har i betydelig grad akselerert rutinemessig koding, skriving av tester og dokumentasjon. Men de forbedrer ikke pålitelig beslutninger om grunnleggende arkitektur. Modeller gjenspeiler tidligere mønstre. Virksomhetsarkitektur krever vurderinger av fremtidige begrensninger, regulatoriske utviklingsbaner og teknologiske satsinger som modeller ikke kan gjøre godt. Team som baserer seg for mye på KI i arkitektoniske beslutninger, har en tendens til å produsere systemer som er lokalt sammenhengende, men globalt sårbare.

Den felles tråden på tvers av alle tre områdene er denne: KI leverer når problemet er velavgrenset, dataene er rene og oppdaterte, og et menneske med domeneekspertise er involvert. Resultatene blir svakere overalt der problemet krever kontekstuell vurdering, organisatorisk endring eller arkitektonisk tenkning som går utover mønstergjenkjenning basert på historiske data.

Hvordan kunstig intelligens sliter med sikkerhet og skalerbarhet i kode

Den mest gjennomgående utfordringen jeg ser, ligger i grenseflaten mellom kode generert av kunstig intelligens og produksjonsklar ingeniørmessig dømmekraft.

Verktøy for kodegenerering med kunstig intelligens er genuint nyttige for godt avgrensede, repetitive oppgaver: standardkode, testtilfeller, dokumentasjon og enkle transformasjoner. Problemene oppstår når team utvider denne tilliten til arkitekturbeslutninger, sikkerhetsfølsom kode eller skaleringskritiske komponenter uten grundig menneskelig gjennomgang.

På sikkerhetssiden introduserer KI-generert kode ofte subtile sårbarheter som slipper gjennom automatisert skanning, men som mislykkes under motstanderbetingelser. Promptinjeksjon er det tydeligste aktuelle eksempelet i agentbaserte KI-systemer. En agent som genererer eller kjører kode basert på brukerinndata uten tilstrekkelig validering av inndata og sandkasseisolering, skaper angrepsflater som er enkle å overse og vanskelige å oppdage i etterkant. Jeg har sett dette mønsteret dukke opp i tidlige distribusjoner av agentbasert KI, der team fokuserte på funksjonalitet og hastighet og behandlet sikkerhetsgjennomgang som et senere trinn.

På skaleringssiden har KI-verktøy en tendens til å generere løsninger som fungerer korrekt i liten skala, men som bygger på skjulte antakelser om datamengde, samtidighet eller forsinkelse, og som først blir synlige under belastning i produksjon. En generert Kafka-konsument som fungerer fint i testing, kan svikte uforutsigbart ved ti tusen hendelser per sekund dersom den genererte koden ikke tar høyde for omfordeling av partisjoner, håndtering av forskyvninger eller håndtering av tilbakestrømning. Modellen kjenner ikke produksjonsmiljøet ditt. Den kjenner mønstre fra treningsdata.

Det praktiske svaret er ikke å slutte å bruke KI til kodegenerering. Det er å behandle KI-generert kode på samme måte som du ville behandlet kode fra en dyktig, men uerfaren utvikler som aldri har sett produksjonssystemet ditt. Gjennomgå den. Test den under realistiske forhold. Og la den aldri komme i nærheten av sikkerhetskritiske eller skaleringskritiske deler uten at en seniorutvikler har godkjent den.

Hva teknologiledere må gjøre nå

Kais tanker

Invester i datagrunnlaget før KI-ambisjonene dine … behandle KI-styring som et arkitekturproblem, ikke et policyproblem … tenk i begge retninger samtidig.

Her er tre råd, i den rekkefølgen de betyr mest:

For det første: invester i datagrunnlaget før KI-ambisjonene dine. Organisasjonene som oppnår målbare resultater med KI, er ikke de som raskest tok i bruk en ny modell. De hadde rene, sanntidsbaserte og styrte data som fløt gjennom systemene sine før KI-samtalen startet. Hvis dataene dine er isolerte, utdaterte eller uten styring, må du fikse det først. Ingen modell kan kompensere for dårlige data i stor skala.

For det andre: behandle KI-styring som et arkitekturproblem, ikke et policyproblem. Det er nødvendig, men ikke tilstrekkelig, å skrive retningslinjer for ansvarlig bruk av KI. Det er prosesslaget som faktisk styrer agentatferd i produksjon: arbeidsflytssperrene, godkjenningstersklene, eskaleringsveiene og revisjonssporene som håndhever grensene uavhengig av hva modellen anbefaler. Bygg dette inn i arkitekturen fra starten. Å ettermontere styring etter utrulling er kostbart, upålitelig og skjer vanligvis etter at noe har gått galt.

For det tredje: tenk i begge retninger samtidig. Presset nedenfra for å lansere KI-bruksområder raskt er reelt og legitimt. Det samme gjelder behovet ovenfra for en strategisk arkitektur som unngår å skape fragmenterte punktløsninger du vil bruke mange år på å rydde opp i. CTO-er jeg ser navigere godt i dette, klarer å holde begge perspektivene samtidig: De beveger seg raskt på konkrete bruksområder, samtidig som de opprettholder en tydelig arkitektonisk ledestjerne som holder disse bruksområdene sammenkoblingsbare og styrbare over tid.

Organisasjonene som vil se tilbake på denne perioden som et konkurransefortrinn, er ikke de som tok i bruk KI tidligst. De bygget infrastrukturen som gjør KI pålitelig, og beveget seg deretter raskt videre med dette fundamentet.

Følg med

Du kan følge med på arbeidet til Kai Waehner på nettstedet hans, bloggen og LinkedIn.

Det kommer flere ekspertintervjuer på The CTO Club!