Global Field CTO opfordrer ledere til at fokusere på datainfrastruktur før AI

Kai Waehner er global CTO for kundevendte løsninger hos Confluent og har rådgivet store virksomheder som BMW og Siemens. Hans fokus er på datainfrastruktur, integrationsstrategi og implementering af AI.

Vi talte med Kai for at forstå, hvorfor så mange AI-initiativer i store virksomheder mislykkes. Her er, hvad han havde at sige.

En fordel ved mønstergenkendelse

Mit navn er Kai Waehner. De seneste ni år har jeg været global CTO for kundevendte løsninger hos Confluent, hvor jeg har arbejdet med hundredvis af virksomheder i Nordamerika, Europa og Asien og Stillehavsområdet. Jeg har rådgivet virksomheder som BMW, Volkswagen, Lufthansa, Siemens, DISH Networks og Globe Telecom. Jeg arbejder med ledere om teknologistrategi, eksekvering af markedsintroduktion, leverandørevaluering, virksomhedsarkitektur og indholdsproduktion.

Rollen som kundevendt CTO adskiller sig fra at lede en enkelt udviklingsorganisation. Jeg arbejder på tværs af snesevis af kundemiljøer samtidig og rådgiver arkitekter og ledere på C-niveau om datainfrastruktur, integrationsstrategi og implementering af AI. Denne bredde giver mig en fordel inden for mønstergenkendelse, som er svær at opnå indefra én enkelt virksomhed.

Min baggrund spænder over hele historien inden for integration af virksomhedsdata: ETL, ESB, iPaaS og API-administration, derefter ni år med fokus på datastrømme med Apache Kafka og Flink som rygrad for hændelsesdrevne arkitekturer og i stigende grad procesorkestrering og AI på tværs af hele spektret fra prædiktiv maskinlæring til generativ og agentbaseret AI. Jeg orienterer regelmæssigt analytikere hos Gartner og Forrester og udgiver min egen forskning, der dækker leverandørlandskaber, arkitekturmønstre og virkelige casestudier fra forskellige brancher. Jeg har også udgivet en bog om datastrømme.

Samtalen om AI-transformation, som jeg har med teknologiledere, handler først og fremmest ikke om modeller. Den handler om infrastrukturen under dem. Agentbaserede AI-systemer, der udfører selvstændige handlinger i virksomheders arbejdsgange, har brug for tre ting for at fungere pålideligt:

• Data i realtid, så de handler ud fra den aktuelle virkelighed
• Procesintelligens, der definerer, hvad de har lov til at gøre
• Indbygget tillid i arkitekturen, ikke kun i modellen

Det er denne konvergens, mit arbejde fokuserer på.

Hvorfor arkitekturlag skal konvergere for at sikre succes med AI

På tværs af brancher ser jeg konsekvent virksomheder investere massivt i tre separate lag: en rygrad til dataintegration, et lag til procesautomatisering og i stigende grad et AI-initiativ. Problemet er, at disse tre næsten aldrig designes til at fungere sammen. Dataintegration flytter data, men forbinder dem ikke med forretningsbeslutninger. Procesautomatisering håndhæver arbejdsgange, men kører på forældet kontekst. AI-agenter genererer anbefalinger eller udfører handlinger, men mangler en styret grænse for, hvad de kan gøre. Hvert lag fungerer isoleret. Den konvergerede arkitektur mangler.

De implementeringsmodeller, jeg ser, varierer betydeligt. Nogle organisationer kører fuldt administreret skybaseret infrastruktur på tværs af AWS, Azure eller GCP, og større globale virksomheder omfatter ofte implementeringer på det kinesiske fastland på Alibaba Cloud, som bevidst holdes adskilt af juridiske, regulatoriske og databeskyttelsesmæssige årsager. Andre driver hybride arkitekturer med lokale datacentre forbundet til skyen, drevet af krav om datasuverænitet eller ældre systemer, som de ikke hurtigt kan flytte. Regulerede brancher som finanssektoren og sundhedsvæsenet har næsten altid krav om flere regioner eller flere skyer, ikke efter eget valg, men på grund af lovgivningsmæssige krav. Produktionsvirksomheder har ofte implementeringer ved kanten, hvor de behandler data tæt på fabriksgulvet, før de samler dem centralt.

På tværs af alle disse miljøer er hændelsesdrevet arkitektur blevet missionskritisk infrastruktur. Apache Kafka er blevet den de facto-standardiserede hændelsesbroker til reel afkobling mellem systemer, behandling i realtid i enhver skala samt hybrid- og multisky-integration. PayPal behandler over en billion Kafka-meddelelser dagligt. New Relic indsamler milliarder af datapunkter i minuttet. Det er ikke eksperimentelle implementeringer. De udgør virksomhedens operationelle rygrad.

Mange virksomheder har allerede de tre dele, de har brug for til pålidelig agentbaseret AI. Det, de mangler, er den arkitektoniske forpligtelse til at få dem til at konvergere.

Hvorfor dataparathed kommer før AI-parathed

Kais tanker

AI-parathed er dataparathed.

Her er, hvad jeg har fundet frem til: AI er ikke den svære del. Det er den underliggende datainfrastruktur.

De fleste AI-initiativer i store virksomheder, som jeg har set lykkes eller mislykkes i løbet af de seneste ni år, afhang i mindre grad af den valgte model og i højere grad af, om organisationen havde et pålideligt, styret fundament i realtid, der kunne forsyne modellen med aktuelle, nøjagtige og troværdige data.

En velafstemt model, der modtager forældede eller inkonsistente data, vil producere upålidelige resultater. Et agentisk AI-system uden et proceslag, der definerer, hvad det kan gøre, vil på et tidspunkt udføre en handling, som ingen kan forklare eller omgøre. Dette er ikke modelproblemer. Det er infrastruktur- og arkitekturproblemer. Og de kan forudsiges fuldstændigt, før man skriver en eneste linje AI-kode.

Den praktiske konsekvens er, at AI-parathed er dataparathed. Før man vælger en model, før man vælger en AI-leverandør, før man lancerer et pilotprojekt, bør en CTO være i stand til at besvare tre spørgsmål ærligt.

1. Har organisationen pålidelig adgang til realtidsdata fra sine driftssystemer?
2. Findes der styrede processer, som definerer, hvad et AI-system selvstændigt må og ikke må gøre?
3. Er der etableret en tillidsramme på arkitekturniveau, ikke kun inde i modellen, som kan håndhæve disse grænser i produktion?

Hvis svaret på et af disse tre spørgsmål er nej, bør AI-rejsen begynde dér og ikke med modellen.

Hvorfor AI skal integreres i eksisterende forretningsprocesser

Den mest betydningsfulde ændring, jeg har gennemført, er at gå fra at udvikle AI som et separat initiativ til at integrere det i eksisterende forretningsprocesser. Dette område får alt for få investeringer og har store konsekvenser. Faktisk vil jeg sige, at de fleste CTO'er bør gå fra at designe nye AI-systemer til at designe, hvordan AI deltager i eksisterende arbejdsgange, hvilke grænser proceslaget håndhæver, og hvordan styring og revisionsspor indbygges — før en eneste model implementeres.

Før jeg foretog dette skift, var mønstret næsten altid det samme. Et AI-projekt begyndte adskilt fra driftssystemerne. Modellen præsterede godt i laboratoriet. I produktion manglede den pålidelig adgang til aktuelle data, en defineret grænse for sine handlinger og integration i de godkendelsesarbejdsgange, som virksomheden var afhængig af. Imponerende demonstration. Mislykket implementering.

Den ændring, jeg nu konsekvent arbejder for, består af to dele.

• For det første skal den eksisterende hændelsesdrevne arkitektur betragtes som fundamentet for AI-anvendelse og ikke som noget, der skal erstattes. Systemerne bliver. Forretningsprocesserne bliver. AI deltager i allerede kørende arbejdsgange, forbruger hændelser i realtid og handler inden for de grænser, som proceslaget definerer.
• For det andet skal AI-sikkerhedsforanstaltninger flyttes ud af modellen og ind i procesorkestreringslaget. En velafstemt model er ikke nok. Pålidelig AI i produktion betyder, at arbejdsgangslaget håndhæver godkendelsespunkter, eskaleringsforløb og revisionsspor for enhver selvstændig handling, agenten foretager.

Alpian, Schweiz' første fuldt licenserede digitale privatbank, er et stærkt eksempel på, at dette gøres rigtigt fra dag ét. Alpian byggede hele sin platform hændelsesdrevet med Apache Kafka som det centrale nervesystem, der forbinder mikrotjenester, domænedataprodukter og AI-agenter. Da de introducerede agentisk AI og RAG i arbejdsgange for kundeinteraktion, var arkitekturen allerede klar. Kafka-hændelser gav agenterne kontekst i realtid. Proceslaget håndhævede compliance-kontroller. De indbyggede kryptering på feltniveau og skemastyring fra begyndelsen.

Resultatet var en reguleret finansiel institution, der kørte selvstændige AI-agenter i styrede arbejdsgange med revisionsspor — præcis det mønster, som de fleste traditionelle virksomheder nu forsøger at eftermontere.

Organisationer, der gør dette rigtigt, betragter AI-anvendelse som en arkitekturfaglig disciplin og ikke som et projektsprint.

Hvorfor dataparathed afgør, om AI-implementeringen lykkes

Efter ni år hos Confluent på tværs af hundredvis af virksomhedsmiljøer har de AI-resultater, jeg har set, været meget ujævne. Forskellen mellem gode og dårlige resultater skyldes næsten altid én ting: om datainfrastrukturen var klar, før AI blev introduceret.

På den positive side er tallene fra veldesignede implementeringer overbevisende. BMW forhindrer over 500 minutters uplanlagt produktionsnedetid om året på en enkelt fabrik. Alpian driver en fuldt reguleret digital bank med agentisk AI indlejret i styrede, auditerbare klientarbejdsgange. Det kvalitative mønster på tværs af vellykkede implementeringer er konsekvent: hurtigere markedsintroduktion, reducerede driftsomkostninger i arbejdsgange med store mængder gentagelser og en mærkbart bedre kundeoplevelse, når AI får adgang til realtidskontekst i stedet for forældede batchdata.

På den negative side er fejlmønstret lige så konsekvent. AI-projekter uden et styret datafundament giver næsten altid det samme resultat: imponerende demonstrationer, mislykkede produktionsimplementeringer. Modellen fungerer i laboratoriet. I produktionen modtager den forældede eller inkonsistente data, hallucinerer i forbindelse med kanttilfælde, træffer beslutninger uden et revisionsspor og svækker i stedet for at opbygge virksomhedens tillid til AI. MIT-forskning anslår, at omkring 95 % af virksomheders AI-pilotprojekter ikke leverer målbar forretningsmæssig effekt. Dette tal stemmer overens med mine observationer fra praksis.

Den seneste fejltilstand, jeg ser, er styring, der tilføjes for sent. Organisationer implementerer agentisk AI og opdager derefter, som regel efter en hændelse, at intet proceslag har defineret, hvad agenten måtte gøre, at der ikke findes nogen eskaleringsvej for usikre modeloutput, og at der ikke er noget revisionsspor, som kan rekonstruere hændelserne. Det er ikke et AI-problem. Det er et arkitekturproblem. Og det kan fuldstændigt forebygges.

Hvorfor AI informerer beslutninger, men mennesker sikrer ansvarlighed

Jeg ser konsekvent et bestemt mønster: AI informerer og accelererer. Den træffer autonome beslutninger inden for definerede grænser. Men mennesker bærer ansvaret for de beslutninger, der har størst betydning.

På den AI-informerede side skaber sammenfatning af forskning, indholdsoprettelse, kodegenerering til velafgrænsede problemer, automatiserede tests og sikkerhedsscanning tydelig værdi. I mit eget arbejde komprimerer AI-værktøjer dage med sammenfatning af analytikerrapporter, kundesamtaler og teknisk dokumentation. Resultatet kræver stadig ekspertvurdering for at blive valideret, men udgangspunktet er kommet meget længere.

På siden med autonome beslutninger bør AI-agenter træffe beslutninger uafhængigt, når risikoen er afgrænset, og processen er velstyret. Svindeldetektion i finansielle tjenester er det tydeligste eksempel. Under en defineret risikotærskel blokerer en AI-agent automatisk en transaktion uden menneskelig indgriben. Når transaktionsbeløbet stiger, og den regulatoriske eksponering vokser, videresender procesorkestreringslaget sagen til en menneskelig analytiker, før der foretages nogen handling. Grænsen er ikke fast. Virksomheden definerer den, arbejdsgangen koder den, og proceslaget håndhæver den – ikke selve modellen.

På den eksplicit menneskelige side trækker jeg grænsen ved beslutninger med store arkitektoniske konsekvenser, strategisk forretningsrisiko eller betydeligt regulatorisk ansvar. Valg af et grundlæggende arkitekturmønster, udvælgelse af en strategisk teknologileverandør, design af styringsmodellen for et agentisk AI-system: Dette er fortsat menneskelige beslutninger. At bevæge sig hurtigere ophæver ikke konsekvenserne af at træffe dem forkert.

Hvorfor AI leverer utilstrækkeligt på tre hovedområder

AI har ikke leveret den tekniske eller teknologiske effekt, som kunderne oprindeligt forventede, på tre områder.

Det første er integration af virksomhedsdata. AI lovede at gøre det markant enklere at forbinde heterogene systemer: skemakortlægning, håndhævelse af datakvalitet, transformationslogik og styring på tværs af komplekse hybride miljøer. I praksis hjælper AI med disse opgaver, men løser dem ikke. En model kan ikke tænke sig ud af den underliggende arkitekturgæld, ældre systemer med udokumenterede datamodeller, inkonsistente semantikker på tværs af forretningsenheder, manglende metadata og fragmenteret ejerskab. Ingeniører skal stadig udføre det vanskelige arbejde.

Det andet er agentisk AI i komplekse virksomhedsarbejdsgange med flere trin. Demonstrationerne er overbevisende. I produktionen fejler agenter uforudsigeligt, når de møder kanttilfælde, som træningsdataene ikke dækkede, når kontekstvinduet ikke indeholder tilstrækkelig aktuel tilstand, eller når proceslaget ikke på en hensigtsmæssig måde opfanger og håndterer agentfejl. Forskellen mellem, hvad en agent kan gøre i et kontrolleret miljø, og hvad vi kan have tillid til, at den gør autonomt i en reguleret produktionsarbejdsgang, er stadig betydelig.

Det tredje er arkitektonisk beslutningstagning. AI-værktøjer har i betydelig grad fremskyndet rutinemæssig kodning, skrivning af tests og dokumentation. Men de forbedrer ikke pålideligt beslutninger om grundlæggende arkitektur. Modeller afspejler tidligere mønstre. Virksomhedsarkitektur kræver vurderinger af fremtidige begrænsninger, regulatoriske udviklingsforløb og teknologiske satsninger, som modeller ikke kan foretage godt. Hold, der i for høj grad stoler på AI til arkitektoniske beslutninger, har en tendens til at skabe systemer, der er lokalt sammenhængende, men globalt skrøbelige.

Den fælles tråd på tværs af alle tre områder er denne: AI leverer, når problemet er velafgrænset, dataene er rene og aktuelle, og et menneske med domæneekspertise er involveret. Den leverer utilstrækkeligt, når problemet kræver kontekstuel vurdering, organisatoriske forandringer eller arkitektonisk tænkning, der rækker ud over mønstergenkendelse baseret på historiske data.

Hvordan AI har svært ved sikkerhed og skalerbarhed i kode

Den mest konsekvente udfordring, jeg ser, er grænsefladen mellem AI-genereret kode og ingeniørmæssig dømmekraft på produktionsniveau.

Værktøjer til AI-kodegenerering er virkelig nyttige til velafgrænsede, gentagne opgaver: standardkode, testcases, dokumentation og enkle transformationer. Problemerne opstår, når teams udvider denne tillid til arkitektoniske beslutninger, sikkerhedsfølsom kode eller skaleringskritiske komponenter uden grundig menneskelig gennemgang.

På sikkerhedsområdet introducerer AI-genereret kode ofte subtile sårbarheder, som består automatiserede scanninger, men fejler under fjendtlige forhold. Prompt-injektion er det tydeligste aktuelle eksempel i agentiske AI-systemer. En agent, der genererer eller udfører kode baseret på brugerinput uden korrekt inputvalidering og sandboxing, skaber angrebsflader, som er nemme at overse og svære at opdage efterfølgende. Jeg har set dette mønster opstå i tidlige implementeringer af agentisk AI, hvor teams fokuserede på funktionalitet og hastighed og behandlede sikkerhedsgennemgang som et senere trin.

På skaleringsområdet har AI-værktøjer en tendens til at generere løsninger, der fungerer korrekt i lille skala, men som bygger på skjulte antagelser om datamængde, samtidighed eller latenstid, der først viser sig under belastning i produktionen. En genereret Kafka-forbruger, der fungerer fint i test, kan fejle uforudsigeligt ved ti tusind hændelser i sekundet, hvis den genererede kode ikke tager højde for omfordeling af partitioner, håndtering af offsets eller håndtering af modtryk. Modellen kender ikke dit produktionsmiljø. Den kender mønstre fra træningsdata.

Den praktiske reaktion er ikke at holde op med at bruge AI til kodegenerering. Det handler om at behandle AI-genereret kode på samme måde, som du ville behandle kode fra en dygtig, men junior ingeniør, der aldrig har set dit produktionssystem. Gennemgå den. Test den under realistiske forhold. Og lad den aldrig komme i nærheden af sikkerhedskritiske eller skaleringskritiske stier, medmindre en senioringeniør godkender den.

Hvad teknologiledere skal gøre nu

Kais tanker

Investér i dit datafundament, før du øger dine AI-ambitioner…behandl AI-styring som et arkitekturproblem, ikke et politikproblem…tænk i begge retninger samtidig.

Her er tre råd, i den rækkefølge de betyder noget:

For det første: Investér i dit datafundament, før du øger dine AI-ambitioner. Organisationer, der opnår målbare AI-resultater, er ikke dem, der hurtigst tog en ny model i brug. De havde rene, realtidsbaserede og styrede data, der flød gennem deres systemer, før AI-samtalen begyndte. Hvis dine data er isolerede, forældede eller uden styring, skal du ordne det først. Ingen model kan kompensere for dårlige data i stor skala.

For det andet: Behandl AI-styring som et arkitekturproblem, ikke et politikproblem. Det er nødvendigt, men ikke tilstrækkeligt, at skrive retningslinjer for ansvarlig brug af AI. Det er proceslaget, der i praksis styrer agentens adfærd i produktionen: arbejdsgangens kontrolpunkter, godkendelsestærsklerne, eskaleringsvejene og revisionssporene, som håndhæver grænserne uanset hvad modellen anbefaler. Indbyg disse i arkitekturen fra starten. At eftermontere styring efter implementeringen er dyrt, upålideligt og sker som regel, efter at noget er gået galt.

For det tredje: Tænk i begge retninger samtidig. Presset nedefra for hurtigt at få AI-anvendelsestilfælde i drift er reelt og legitimt. Det samme er behovet ovenfra for en strategisk arkitektur, der undgår at skabe fragmenterede punktløsninger, som du vil bruge årevis på at få skilt ad. De CTO'er, jeg ser navigere godt i dette, kan rumme begge dele samtidig: De bevæger sig hurtigt på specifikke anvendelsestilfælde, samtidig med at de bevarer et klart arkitektonisk pejlemærke, der holder disse anvendelsestilfælde komponerbare og styrbare over tid.

De organisationer, der vil se tilbage på denne periode som en konkurrencefordel, er ikke dem, der tog AI i brug først. De byggede infrastrukturen, der gør AI troværdig, og bevægede sig derefter hurtigt på dette fundament.

Følg med

Du kan følge med i Kai Waehners arbejde på hans hjemmeside, blog og LinkedIn.

Der kommer flere ekspertinterviews på The CTO Club!