Wereldwijde technisch directeur voor klantgerichte activiteiten spoort leiders aan om zich vóór AI op data-infrastructuur te richten

De rol van Field CTO verschilt van het leiden van één engineeringorganisatie. Ik werk tegelijkertijd in tientallen klantomgevingen en adviseer architecten en directieleden over data-infrastructuur, integratiestrategie en AI-adoptie. Die breedte geeft me een voordeel op het gebied van patroonherkenning dat moeilijk vanuit één bedrijf te verkrijgen is.

Mijn achtergrond omvat de volledige geschiedenis van enterprise-dataintegratie: ETL, ESB, iPaaS en API Management, gevolgd door negen jaar waarin ik me richtte op datastreaming met Apache Kafka en Flink als basis voor eventgedreven architecturen, en in toenemende mate op procesorkestratie en AI over het volledige spectrum, van voorspellend machinaal leren tot generatieve en agentische AI. Ik informeer analisten van Gartner en Forrester regelmatig en publiceer mijn eigen onderzoek, waarin leverancierslandschappen, architectuurpatronen en praktijkgerichte casestudy's uit verschillende sectoren aan bod komen. Daarnaast heb ik een boek over datastreaming gepubliceerd.

Het gesprek over AI-transformatie dat ik met technologieleiders voer, gaat niet in de eerste plaats over modellen. Het gaat over de infrastructuur eronder. Agentische AI-systemen die autonoom acties uitvoeren binnen bedrijfsprocessen hebben drie dingen nodig om betrouwbaar te werken:

• Realtimegegevens, zodat ze handelen op basis van de huidige werkelijkheid
• Procesintelligentie om vast te leggen wat ze mogen doen
• Vertrouwen dat in de architectuur is ingebouwd, niet alleen in het model

Mijn visie richt zich op die convergentie.

You should also read

• 12 beste nieuwsbrieven voor IT-leidinggevenden om u in 2026 op te abonneren

• 12 beste CIO-nieuwsbrieven om je in 2026 op te abonneren

• 11 softwaretestconferenties om wereldwijd bij te wonen in 2026

Waarom architectuurlagen moeten convergeren voor succesvolle AI

In alle sectoren zie ik ondernemingen consequent zwaar investeren in drie afzonderlijke lagen: een ruggengraat voor dataintegratie, een laag voor procesautomatisering en in toenemende mate een AI-initiatief. Het probleem is dat deze drie bijna nooit zijn ontworpen om samen te werken. Dataintegratie verplaatst data, maar legt geen verbinding met zakelijke beslissingen. Procesautomatisering dwingt workflows af, maar werkt met verouderde context. AI-agenten genereren aanbevelingen of voeren acties uit, maar missen een beheerde grens rond wat ze mogen doen. Elke laag werkt geïsoleerd. De geconvergeerde architectuur ontbreekt.

De implementatiemodellen die ik zie, variëren aanzienlijk. Sommige organisaties draaien volledig beheerde cloudnative infrastructuur op AWS, Azure of GCP, en grotere internationale ondernemingen omvatten vaak implementaties op het Chinese vasteland op Alibaba Cloud, die bewust gescheiden worden gehouden om juridische, regelgevende en privacyredenen. Andere werken met hybride architecturen waarin lokale datacenters met de cloud zijn verbonden, vanwege vereisten rond datasoevereiniteit of verouderde systemen die ze niet snel kunnen verplaatsen. Gereguleerde sectoren zoals financiële dienstverlening en gezondheidszorg hebben vrijwel altijd vereisten voor meerdere regio's of meerdere clouds, niet uit vrije keuze maar vanwege complianceverplichtingen. Klanten in de productiesector hebben vaak implementaties aan de rand waarbij ze data dicht bij de productievloer verwerken voordat ze die centraal verzamelen.

In al deze omgevingen is een eventgedreven architectuur bedrijfskritische infrastructuur geworden. Apache Kafka heeft zich ontwikkeld tot de feitelijke standaard voor eventbrokers die zorgen voor echte ontkoppeling tussen systemen, realtimeverwerking op elke schaal en hybride integratie en multicloudintegratie. PayPal verwerkt dagelijks meer dan een biljoen Kafka-berichten. New Relic neemt miljarden datapunten per minuut op. Dit zijn geen experimentele implementaties. Ze vormen de operationele ruggengraat van het bedrijf.

Veel ondernemingen beschikken al over de drie onderdelen die ze nodig hebben voor betrouwbare agentische AI. Wat ontbreekt, is de architecturale toewijding om ze te laten convergeren.

Waarom datagereedheid voorafgaat aan AI-gereedheid

Kais gedachten

AI-gereedheid is datagereedheid.

Dit is wat ik heb vastgesteld: AI is niet het moeilijke onderdeel. Dat is de data-infrastructuur eronder.

De meeste AI-initiatieven voor ondernemingen die ik de afgelopen negen jaar heb zien slagen of mislukken, waren minder afhankelijk van het gekozen model dan van de vraag of de organisatie beschikte over een betrouwbare, beheerde realtimebasis om dat model te voeden met actuele, nauwkeurige en betrouwbare data.

Een goed afgestemd model dat verouderde of inconsistente gegevens ontvangt, zal onbetrouwbare uitvoer produceren. Een agentisch AI-systeem zonder proceslaag die bepaalt wat het kan doen, zal uiteindelijk een actie uitvoeren die niemand kan verklaren of terugdraaien. Dit zijn geen modelproblemen. Het zijn infrastructuur- en architectuurproblemen. En deze zijn volledig voorspelbaar voordat er ook maar één regel AI-code is geschreven.

De praktische conclusie is dat AI-gereedheid gegevensgereedheid is. Voordat een model wordt geselecteerd, voordat een AI-leverancier wordt gekozen en voordat een pilot wordt gelanceerd, moet een CTO drie vragen eerlijk kunnen beantwoorden.

1. Heeft de organisatie betrouwbare toegang tot realtimegegevens uit haar operationele systemen?
2. Zijn er beheerde processen die bepalen wat een AI-systeem wel en niet autonoom mag doen?
3. Is er op architectuurniveau een vertrouwenskader aanwezig, niet alleen binnen het model, dat deze grenzen in productie kan afdwingen?

Als het antwoord op een van deze drie vragen nee is, moet de AI-reis daar beginnen en niet bij het model.

Waarom AI in bestaande bedrijfsprocessen moet worden geïntegreerd

De belangrijkste verandering die ik heb doorgevoerd, is de verschuiving van het bouwen van AI als een afzonderlijk initiatief naar het integreren ervan in bestaande bedrijfsprocessen. Hier wordt veel te weinig in geïnvesteerd, terwijl de gevolgen groot zijn. Ik zou zelfs zeggen dat de meeste CTO's moeten verschuiven van het ontwerpen van nieuwe AI-systemen naar het ontwerpen van de manier waarop AI deelneemt aan bestaande werkstromen, welke grenzen de proceslaag afdwingt en hoe beheer en controleerbaarheid worden ingebouwd — voordat er ook maar één model wordt ingezet.

Voordat ik deze verschuiving maakte, was het patroon vrijwel altijd hetzelfde. Een AI-project begon los van de operationele systemen. Het model presteerde goed in het laboratorium. In productie ontbrak het aan betrouwbare toegang tot actuele gegevens, een duidelijke grens voor zijn acties en integratie met de goedkeuringsworkflows waarvan het bedrijf afhankelijk was. Indrukwekkende demo. Mislukte implementatie.

De verandering waar ik nu consequent op aandring, bestaat uit twee onderdelen.

• Ten eerste: behandel de bestaande gebeurtenisgestuurde architectuur als de basis voor AI-adoptie, in plaats van als een doel dat moet worden vervangen. De systemen blijven. De bedrijfsprocessen blijven. AI neemt deel aan werkstromen die al actief zijn, verwerkt realtimegebeurtenissen en handelt binnen de grenzen die de proceslaag definieert.
• Ten tweede: verplaats de veiligheidsmaatregelen voor AI uit het model naar de procesorkestratielaag. Een goed afgestemd model is niet voldoende. Betrouwbare AI in productie betekent dat de workflowlaag goedkeuringspoorten, escalatiepaden en audittrails afdwingt voor elke autonome actie die de agent uitvoert.

Alpian, de eerste volledig vergunde digitale private bank van Zwitserland, is vanaf dag één een sterk voorbeeld van hoe dit goed kan worden gedaan. Alpian bouwde zijn volledige platform gebeurtenisgestuurd, met Apache Kafka als centraal zenuwstelsel dat microservices, domeingegevensproducten en AI-agents met elkaar verbindt. Toen het bedrijf agentische AI en RAG introduceerde in workflows voor klantinteractie, was de architectuur al gereed. Kafka-gebeurtenissen gaven de agents realtimecontext. De proceslaag handhaafde de nalevingscontroles. Vanaf het begin werden versleuteling op veldniveau en schemabeheer ingebouwd.

Het resultaat was een gereguleerde financiële instelling die autonome AI-agents uitvoert binnen beheerde, controleerbare workflows — precies het patroon dat de meeste traditionele ondernemingen nu achteraf proberen in te bouwen.

Organisaties die dit goed aanpakken, behandelen AI-adoptie als een architectuurdiscipline en niet als een projectsprint.

Organisaties die dit goed aanpakken, behandelen AI-adoptie als een architectuurdiscipline en niet als een projectsprint…Het verschil tussen goede en slechte resultaten komt vrijwel altijd voort uit de vraag of de gegevensinfrastructuur gereed was voordat AI werd geïntroduceerd.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Kai WaehnerOpens new window

Wereldwijde CTO voor klantrelaties, Confluent

Waarom gegevensgereedheid bepalend is voor succesvol gebruik van AI

Na negen jaar bij Confluent in honderden bedrijfsomgevingen zijn de AI-resultaten die ik heb gezien zeer wisselend. Het verschil tussen goede en slechte resultaten komt vrijwel altijd voort uit één factor: of de gegevensinfrastructuur gereed was voordat AI werd geïntroduceerd.

Aan de positieve kant zijn de cijfers van goed ontworpen implementaties overtuigend. BMW voorkomt jaarlijks meer dan 500 minuten ongeplande productiestilstand in één fabriek. Alpian exploiteert een volledig gereguleerde digitale bank met agentische AI die is ingebed in beheerde, controleerbare klantworkflows. Het kwalitatieve patroon bij succesvolle implementaties is consistent: een snellere tijd tot marktintroductie, lagere operationele kosten in repetitieve workflows met een hoog volume en een aanzienlijk betere klantervaring wanneer AI toegang heeft tot realtime context in plaats van verouderde batchgegevens.

Aan de negatieve kant is het patroon van mislukkingen al even consistent. AI-projecten zonder een beheerde gegevensbasis leveren bijna altijd hetzelfde resultaat op: indrukwekkende demo's, maar mislukte productie-implementaties. Het model werkt in het laboratorium. In productie ontvangt het verouderde of inconsistente gegevens, hallucineert het bij uitzonderingssituaties, onderneemt het acties zonder audittrail en ondermijnt het het vertrouwen van de organisatie in AI in plaats van dit op te bouwen. Onderzoek van MIT schat dat ongeveer 95% van de AI-proefprojecten binnen ondernemingen geen meetbare bedrijfsimpact oplevert. Dit cijfer komt overeen met mijn waarnemingen in de praktijk.

De meest recente faalmodus die ik zie, is dat governance te laat wordt toegevoegd. Organisaties implementeren agentische AI en ontdekken vervolgens, meestal na een incident, dat geen enkele proceslaag heeft vastgelegd wat de agent mocht doen, dat er geen escalatiepad is voor onzekere modeluitvoer en dat er geen audittrail is om gebeurtenissen te reconstrueren. Dat is geen AI-probleem. Het is een architectuurprobleem. En het is volledig te voorkomen.

Waarom AI beslissingen ondersteunt, maar mensen verantwoordelijk blijven

Ik zie consequent een bepaald patroon: AI informeert en versnelt. Het neemt autonome beslissingen binnen vastgestelde grenzen. Maar mensen dragen de verantwoordelijkheid voor de beslissingen die er het meest toe doen.

Aan de kant van door AI ondersteunde werkzaamheden leveren onderzoekssynthese, contentcreatie, codegeneratie voor duidelijk afgebakende problemen, geautomatiseerd testen en beveiligingsscans duidelijke waarde. In mijn eigen werk brengen AI-tools dagen aan synthese van analistenrapporten, klantgesprekken en technische documentatie terug tot een veel kortere tijd. De uitvoer vereist nog steeds deskundig oordeel om deze te valideren, maar het vertrekpunt ligt veel verder vooruit.

Aan de kant van autonome besluitvorming zouden AI-agenten zelfstandig moeten beslissen wanneer het risico begrensd is en het proces goed wordt beheerd. Fraudedetectie in de financiële dienstverlening is het duidelijkste voorbeeld. Onder een vastgestelde risicodrempel blokkeert een AI-agent automatisch een transactie zonder dat er een mens aan te pas komt. Naarmate de transactiegrootte toeneemt en de blootstelling aan regelgeving groter wordt, stuurt de procesorkestratielaag de zaak door naar een menselijke analist voordat er actie wordt ondernomen. De grens ligt niet vast. Het bedrijf bepaalt deze, de workflow legt deze vast en de proceslaag handhaaft deze, niet het model zelf.

Aan de kant die expliciet menselijk blijft, trek ik de grens bij beslissingen met grote architecturale gevolgen, strategisch bedrijfsrisico of aanzienlijke wettelijke verantwoordelijkheid. Het kiezen van een fundamenteel architectuurpatroon, het selecteren van een strategische technologieleverancier en het ontwerpen van het governancemodel voor een agentisch AI-systeem: dit blijven menselijke beslissingen. Sneller handelen maakt de gevolgen van verkeerde beslissingen niet ongedaan.

Waarom AI op drie hoofdgebieden achterblijft

AI heeft op drie gebieden niet de technische of technische impact geleverd die klanten aanvankelijk verwachtten.

Het eerste gebied is de integratie van bedrijfsgegevens. AI beloofde het verbinden van heterogene systemen drastisch te vereenvoudigen: schemamapping, het afdwingen van gegevenskwaliteit, transformatielogica en governance in complexe hybride omgevingen. In de praktijk helpt AI bij deze taken, maar lost het ze niet op. Een model kan zich niet uit de onderliggende architecturale schuld redeneren, zoals verouderde systemen met niet-gedocumenteerde gegevensmodellen, inconsistente semantiek tussen bedrijfseenheden, ontbrekende metadata en versnipperd eigenaarschap. Engineers moeten het moeilijke werk nog steeds doen.

Het tweede gebied is agentische AI in complexe bedrijfsworkflows met meerdere stappen. De demo's zijn overtuigend. In productie falen agenten onvoorspelbaar wanneer ze uitzonderingssituaties tegenkomen die niet in de trainingsgegevens voorkwamen, wanneer het contextvenster niet genoeg actuele status bevat of wanneer de proceslaag fouten van agenten niet op een elegante manier opvangt en afhandelt. De kloof tussen wat een agent in een gecontroleerde omgeving kan doen en wat we hem autonoom kunnen toevertrouwen in een gereguleerde productieworkflow is nog steeds aanzienlijk.

Het derde gebied is architecturale besluitvorming. AI-tools hebben routinematige codering, het schrijven van tests en documentatie aanzienlijk versneld. Maar ze verbeteren beslissingen over fundamentele architectuur niet betrouwbaar. Modellen weerspiegelen patronen uit het verleden. Bedrijfsarchitectuur vereist oordeelsvermogen over toekomstige beperkingen, regelgevende ontwikkelingen en technologische keuzes die modellen niet goed kunnen maken. Teams die voor architecturale beslissingen te sterk op AI vertrouwen, produceren doorgaans systemen die lokaal coherent maar globaal kwetsbaar zijn.

De gemeenschappelijke factor in alle drie de gebieden is deze: AI levert resultaten wanneer het probleem duidelijk is afgebakend, de gegevens schoon en actueel zijn en een mens met domeinexpertise betrokken is. AI schiet tekort waar het probleem contextueel oordeel, organisatorische verandering of architecturaal denkvermogen vereist dat verder gaat dan patroonherkenning op basis van historische gegevens.

Hoe AI worstelt met beveiliging en schaalbaarheid in code

De meest consistente uitdaging die ik zie, ligt op het grensvlak tussen door AI gegenereerde code en technisch oordeel op productieniveau.

Tools voor het genereren van AI-code zijn echt nuttig voor goed afgebakende, repetitieve taken: standaardcode, testgevallen, documentatie en eenvoudige transformaties. De problemen ontstaan wanneer teams dat vertrouwen uitbreiden naar architectuurbeslissingen, beveiligingsgevoelige code of schaalbaarheidskritieke componenten zonder grondige menselijke controle.

Op het gebied van beveiliging introduceert door AI gegenereerde code vaak subtiele kwetsbaarheden die geautomatiseerde scans doorstaan, maar onder vijandige omstandigheden falen. Promptinjectie is het duidelijkste huidige voorbeeld in agentische AI-systemen. Een agent die code genereert of uitvoert op basis van gebruikersinvoer zonder goede invoervalidatie en isolatie in een sandbox, creëert aanvalsvlakken die gemakkelijk over het hoofd worden gezien en achteraf moeilijk te detecteren zijn. Ik heb dit patroon zien ontstaan bij vroege implementaties van agentische AI, waarbij teams zich richtten op mogelijkheden en snelheid en beveiligingscontrole als een latere stap beschouwden.

Op het gebied van schaalbaarheid genereren AI-tools doorgaans oplossingen die op kleine schaal correct werken, maar verborgen aannames bevatten over datavolume, gelijktijdigheid of latentie die pas bij productbelasting aan het licht komen. Een gegenereerde Kafka-consument die tijdens het testen prima werkt, kan bij tienduizend gebeurtenissen per seconde onvoorspelbaar falen als de gegenereerde code geen rekening houdt met het opnieuw verdelen van partities, offsetbeheer of het omgaan met tegendruk. Het model kent jouw productieomgeving niet. Het kent patronen uit trainingsdata.

De praktische reactie is niet dat je moet stoppen met het gebruik van AI voor het genereren van code. Je moet door AI gegenereerde code behandelen zoals je code zou behandelen van een bekwame maar junior ontwikkelaar die jouw productiesysteem nog nooit heeft gezien. Controleer de code. Test deze onder realistische omstandigheden. En laat de code nooit in de buurt komen van beveiligingskritieke of schaalbaarheidskritieke paden tenzij een senior ontwikkelaar zijn goedkeuring heeft gegeven.

Wat technologieleiders nu moeten doen

Kai's gedachten

Investeer in je databasis voordat je AI-ambities nastreeft…behandel AI-governance als een architectuurprobleem, niet als een beleidsprobleem…denk tegelijkertijd in beide richtingen.

Hier zijn drie adviezen, in de volgorde waarin ze ertoe doen:

Investeer ten eerste in je databasis voordat je AI-ambities nastreeft. Organisaties die meetbare AI-resultaten behalen, zijn niet de organisaties die het snelst zijn overgestapt op een nieuw model. Voordat het AI-gesprek begon, beschikten ze al over schone, realtime beheerde gegevens die door hun systemen stroomden. Als je gegevens verspreid, verouderd of niet beheerd zijn, los dat dan eerst op. Geen enkel model kan op grote schaal compenseren voor slechte gegevens.

Behandel AI-governance ten tweede als een architectuurprobleem, niet als een beleidsprobleem. Richtlijnen opstellen voor verantwoord AI-gebruik is noodzakelijk, maar niet voldoende. Het procesniveau bepaalt het gedrag van agents in productie: de workflowpoorten, de goedkeuringsdrempels, de escalatiepaden en de auditsporen die grenzen afdwingen, ongeacht wat het model aanbeveelt. Bouw deze vanaf het begin in de architectuur in. Governance achteraf toevoegen is duur, onbetrouwbaar en gebeurt meestal pas nadat er iets is misgegaan.

Denk ten derde tegelijkertijd in beide richtingen. De druk van onderaf om AI-toepassingen snel uit te rollen is reëel en legitiem. Dat geldt ook voor de top-downbehoefte aan een strategische architectuur die voorkomt dat er versnipperde puntoplossingen ontstaan waar je jarenlang mee bezig bent om ze weer uit elkaar te halen. CTO's die ik dit goed zie aanpakken, kunnen beide tegelijkertijd vasthouden: snel vooruitgaan met specifieke toepassingen en tegelijkertijd een duidelijk architectonisch richtsnoer behouden dat ervoor zorgt dat die toepassingen op de lange termijn combineerbaar en beheersbaar blijven.

De organisaties die op deze periode zullen terugkijken als een concurrentievoordeel, zijn niet de organisaties die AI het vroegst hebben ingevoerd. Ze hebben de infrastructuur gebouwd om AI betrouwbaar te maken en zijn vervolgens snel voortgebouwd op die basis.

Volg Kai

Je kunt het werk van Kai Waehner volgen op zijn website, blog en LinkedIn.

Er komen meer interviews met experts aan op The CTO Club!