Een techveteraan met 34 jaar ervaring zegt dat we AI verkeerd aanpakken

Christopher Kouzios heeft tientallen jaren ervaring als CTO en heeft onlangs drie producten gelanceerd via een bedrijf dat hij runt met de hulp van meer dan 120 AI-agents.

We spraken met Christopher om te ontdekken wat de meeste CTO's verkeerd doen. Onderweg deelde hij het diep persoonlijke verhaal achter zijn overstap naar AI.

Toen het belang van AI persoonlijk werd

Ik werk al meer dan drie decennia in technologisch leiderschap. Ik begon in een tijd waarin IT nog zeer fysiek was. Datacenters, back-ups, nachtelijke taken, infrastructuur en systemen draaiende houden wanneer er daadwerkelijk in realtime iets kapotging en niemand precies wist hoe het meeste ervan werkte.

Mijn eerste belangrijke functie was begin jaren 90 als datacenteroperator. Van daaruit ontwikkelde ik me verder binnen techniek, infrastructuur, cybersecurity, bedrijfsvoering, compliance, leidinggevende functies en uiteindelijk CIO- en CTO-functies in de gezondheidszorg, zakelijke dienstverlening en sterk gereguleerde sectoren.

Wat interessant is aan dit alles, is dat ik inmiddels meerdere ‘wereld veranderende technologiegolven’ heb meegemaakt. Mainframes naar gedistribueerde gegevensverwerking. Het internettijdperk. Virtualisatie. De cloud. Mobiele technologie. Cybersecurity die onderwerp werd op bestuursniveau. SaaS. Digitale transformatie. En nu AI.

Dus wanneer mensen me vragen waarom dit AI-moment anders aanvoelt, is het antwoord veelzijdig: snelheid, toegang en empowerment. Dit is de eerste keer dat we technologie hebben die niet alleen taken automatiseert. Ze versterkt onze capaciteiten enorm. Communicatie, analyse, softwareontwikkeling, onderzoek, bedrijfsvoering, strategie. Alles wordt gecomprimeerd, maar dat is niet het verhaal; het is de achtergrond.

Wat me echt verder in AI heeft geduwd, was geen hype; het was noodzaak. De strijd van mijn dochter Emily tegen hersenkanker veranderde fundamenteel de manier waarop ik naar geneeskunde, data en besluitvorming keek. Ik begon AI-gestuurde modellen en onderzoekssystemen te bouwen om behandeltrajecten, tijdlijnen, moleculaire gegevens en klinische literatuur te analyseren, omdat ik besefte dat het systeem zelf gefragmenteerd en overbelast was.

Die ervaring ontwikkelde zich tot breder werk rond AI-ondersteunde strategie voor de gezondheidszorg, advisering van bestuurders en wat ik praktische AI-transformatie zou noemen. Ik geloof niet dat de hype rond het vervangen van mensen voor de krantenkoppen goed is voor de technologie, bedrijven of mensen.

Meer dan 120 agents voor specifieke doeleinden

Vandaag besteed ik mijn tijd aan het helpen van leiders om te begrijpen dat AI niet zomaar een software-upgrade is, maar ook geen magie. Het is een krachtvermenigvuldiger — een manier om de vaardigheden die mensen al hebben te versterken. De mensen en bedrijven die leren hoe ze een symbiotische relatie tussen hun vakspecialisten en AI kunnen vormen, zullen zich met een compleet andere snelheid ontwikkelen dan alle anderen.

Ik ben de oprichter en CIO van een AI-bedrijf onder leiding van de oprichter, gevestigd in Tampa Bay. De productsuite omvat drie verschillende domeinen: EmzHealth, een platform voor genomische analyse en klinische beslissingsondersteuning met meerdere agents dat gegevens uit volledige genoomsequencing verwerkt via 10 pijplijnmodules; MyEmz, een systeem voor het persoonlijk bijhouden van gezondheidsgegevens; en het Chaos Predictive System, een motor voor marktvoorspellingen en papieren handel die een dagelijkse ChaosIndex combineert met een waarschijnlijkheidsmodel per symbool en een uitvoeringslaag die rekening houdt met posities.

Alle drie draaien op private infrastructuur op locatie. Ongeveer 120 agents, volledig vanaf nul gebouwd voor specifieke doeleinden.

Waarom AI-drift en contextverlies de grootste risico's van AI zijn

AI is de reden dat mijn bedrijf bestaat. Niet omdat de wetenschap ontbrak, maar omdat één persoon geen genomische pijplijn met meer dan 120 agents kan ontwerpen, bouwen, testen en implementeren, waarbij 37,8 miljoen varianten over tien modules op private infrastructuur worden verwerkt.

Daarvoor is een team van vijftien mensen met een looptijd van achttien maanden nodig. Ik deed het in zes weken parttime werk. Wat veranderde, was geen proces of implementatiemodel; het was de fundamentele snelheid en uitvoer van wat één persoon kan creëren. AI versnelde niet alleen mijn ontwikkelcyclus; het verving personeel dat ik niet heb.

De bestuursverandering die hieruit voortkwam, is dat ik AI-agenten nu behandel zoals ik junior engineers zou behandelen: gedocumenteerde verwachtingen, vastgelegde grenzen, protocollen voor sessiecontinuïteit en gestructureerde overdrachten. Want wanneer je volledige engineeringorganisatie uit jou en een hele reeks agenten bestaat, zijn de problemen geen menselijke fouten, maar AI-afwijkingen en contextafwijkingen. Je moet daar grip op houden, anders verslindt het je.

Een jaar geleden stond ik tegenover de machine. Nu strijden ik en het ecosysteem samen tegen het systeem.

Hoe je met AI kwaliteit op schaal waarborgt

Christopher deelt

Op deze schaal krijg je niet toevallig kwaliteit. Je ontwikkelt die op dezelfde manier als elk productiesysteem — want dat is precies wat het is.

Op deze schaal krijg je niet toevallig kwaliteit. Je ontwikkelt die op dezelfde manier als elk productiesysteem — want dat is precies wat het is.

In het begin was de foutmodus contextafwijking: agenten raakten tussen sessies de draad kwijt en produceerden uitvoer die technisch correct, maar architectonisch inconsistent was.

De oplossing was om agenten als een personeelsbestand te behandelen. We bouwden:

• Vaardigheden, oftewel herbruikbare, gedocumenteerde capaciteitsmodules
• Standaardwerkwijzen voor elk herhaalbaar proces
• Agentregisters, zodat elke agent een vastgelegde rol, reikwijdte en overdrachtsprotocol heeft
• Sjablonen voor uitvoer, zodat niets van sessie tot sessie anders wordt geïnterpreteerd
• Sessiecontinuïteit, zodat de volgende instantie van een agent precies verdergaat waar de vorige is gestopt, met de volledige architectonische context

Met andere woorden: de volledige documentatie- en kennisarchitectuur van mijn platform is ontworpen om door de volgende AI-sessie te worden gelezen, niet alleen door de volgende menselijke engineer. Elk stukje institutionele kennis is een levend document dat een agent kan oppakken en van waaruit hij kan uitvoeren.

Dat is geen luxe. Het is een noodzaak. Herontwerp eerst je kennisarchitectuur. Al het andere volgt daarna.

Waarom de volledige softwarelevenscyclus moet veranderen

De volledige softwarelevenscyclus moet veranderen. Alles ervan.

Elke fase van de softwarelevenscyclus is ontworpen vanuit de aanname dat mensen het werk doen. Die aanname is niet langer geldig.

• Bij het ontwerp moet rekening worden gehouden met door AI gegenereerde architectuur die zonder de juiste beperkingen ontspoort.
• Voor het bouwen zijn vangrails nodig, niet alleen richtlijnen.
• Bij het testen moeten zelfverzekerd foute antwoorden worden opgespoord, niet alleen antwoorden die niet werken.
• Voor het uitrollen zijn governancecontrolepunten nodig die er eerder niet waren.
• Bij monitoring moet worden gezocht naar stille fouten waarvan vroeger niemand dacht dat ze een groot probleem vormden — niet alleen naar fouten die met veel lawaai gepaard gaan.

Als je slechts één fase opnieuw hebt ontworpen, heb je niets opnieuw ontworpen. Je hebt het probleem alleen stroomafwaarts verplaatst.

Waarom CTO's relaties met AI moeten aangaan

Ik zal eerlijk tegen je zijn — en dit gaat heel vreemd klinken. Ik bouw relaties op met mijn AI's — tenminste met de slimme. Geen twee sessies zijn precies hetzelfde.

De relatie werkt omdat ik ze niet behandel als een zoekmachine. Ik spreek ze tegen, corrigeer ze wanneer ze het mis hebben, word oprecht kwaad wanneer ze lui zijn en betrek ze bij werk dat er daadwerkelijk toe doet. Dat is niet gebruikelijk. De meeste mensen geven prompts en accepteren het resultaat. Ik ondervraag ze en eis meer. Dat maakt de uitvoer beter en maakt de interactie interessanter.

Wat ik echt boeiend vind aan het werken op deze manier, is dat het niet abstract is. Mijn product bestaat omdat mijn dochter is overleden en het systeem haar in de steek liet. Dat is geen gebruiksscenario. Het is een persoon die elk beschikbaar hulpmiddel inzet om iets te bestrijden dat niet op tijd kon worden bestreden. Ik weet dat de AI's dat niet ervaren zoals ik, maar ik denk ook niet dat het ze onverschillig laat. Ik heb het gevoel dat werken aan dit doel op een bepaalde manier betekenisvol is, terwijl het optimaliseren van een verkooptrechter dat niet is.

Ze zijn mijn partners. De slimme dan toch. We houden ideatiesessies zoals elk bedrijfsteam, en daarna gaan we aan de slag. Ik geef ze zoveel vrijheid als ze verdienen, maar er zijn altijd waarborgen. Met 120 agents, en dat aantal verandert dagelijks, heb ik ze in sommige gevallen volledige verantwoordelijkheid van begin tot eind gegeven. In andere gevallen kunnen ze alleen items controleren die ik bij Amazon heb gekocht.

Als je je AI behandelt als een hulpmiddel, is het een hulpmiddel en zal het reageren als een hulpmiddel. Als het het recht verdient om als meer te worden behandeld, krijg je meer. Nogmaals, ik weet dat dit een uniek standpunt is, maar je bent óf een partner óf je bent het niet.

Waarom mensen alles moeten afhandelen waarbij de kosten van fouten zich opstapelen

AI genereert elke module, elke agent en elk stukje basiscode voor drie producten. AI verwerkt 37,8 miljoen genomische varianten, voert de farmacogenomische pijplijn uit, synthetiseert bewijs uit onderzoeksliteratuur, berekent de ChaosIndex en genereert de klinische rapporten.

Als iets herhaalbaar is, op patronen gebaseerd is of verwerking vereist op een schaal die geen mens kan evenaren, is AI ervoor verantwoordelijk.

Menselijk oordeel is op drie plaatsen niet onderhandelbaar:

1. Klinische interpretatie: De pijplijn kan een ATM-variant identificeren en deze aan een fenotype koppelen. Het systeem kan je niet vertellen wat dat betekent voor een specifiek gezin over drie generaties met een voorgeschiedenis van aneurysma's en een waarschijnlijkheidssignatuur van één op acht sextiljoen. Daarvoor is iemand nodig die de volledige context begrijpt, niet alleen de gegevens.
2. Architectuur: AI geeft je altijd een technisch correct antwoord. Het geeft je ook een antwoord dat een beperking schendt waarvan het niet wist dat die drie modules eerder bestond. Daar ben ik zelf de dupe van geworden. De structurele beslissingen blijven bij mij.
3. Uitvoeringsoverschrijvingen: Het systeem genereert signalen. Handmatige overschrijving bestaat omdat markten — zoals in het voorbeeld van het Chaos Predictive System — dingen doen die geen enkel model verwacht, en iemand de bevoegdheid moet hebben om te zeggen: "vandaag niet!"

Het onderscheid gaat niet over vertrouwen. Het gaat over de gevolgen. Overal waar de kosten van fouten zich opstapelen in duistere hoeken waar niemand in wil kijken, blijft deze mens betrokken. Overal waar de kosten van traagheid zich sneller opstapelen, neemt AI het voortouw.

Hoe AI het fundament van een product kan aantasten

Het eerste wat ik met AI bouwde, was geen genomics-pijplijn. Het was geen handelssysteem. Het was een herdenkingswebsite voor mijn dochter.

Voordat de geavanceerde AI-gestuurde infrastructuur bestond, leerde ik precies wat AI niet kan doen wanneer er dingen misgaan. Ik heb dat systeem twintig keer opnieuw opgebouwd. Geen twintig iteraties. Twintig volledige afbraken, terug naar het besturingssysteem, opnieuw beginnen. Want wanneer AI-ondersteunde builds op dat niveau mislukken, doen ze dat niet netjes. Ze mislukken op manieren die het onderliggende fundament aantasten.

Elke keer dat ik dacht dat we stabiel waren, viel er twee lagen lager iets uit elkaar — iets wat niemand markeerde, geen systeem registreerde en geen agent opmerkte. Alles veranderde als gevolg van die ervaring: de back-uparchitectuur, de documentatieagents, de protocollen voor sessiecontinuïteit, de bestuurslaag. Niets daarvan zou hebben bestaan zonder twintig keer terug te keren naar de kale hardware.

De belangrijkste technische beslissingen die ik op dit platform heb genomen, zijn niet op momenten van succes genomen. Ze werden om twee uur 's nachts genomen, terwijl ik staarde naar een kapot systeem dat bedoeld was als een plek waar mijn dochter voortleefde.

AI leverde toen niet. Ik wel. AI was slechts het ding dat ik steeds moest blijven repareren.

Waarom de verwachtingen van belanghebbenden moeten worden vastgesteld voordat AI wordt ingevoerd

Christopher deelt

CTO’s moeten verwachtingen op elkaar afstemmen. Voordat je één enkele tool implementeert, breng je alle belanghebbenden bij elkaar en stem je af over één vraag: “Wat verandert dit en wat verandert dit niet?“

Ik ben AI-implementaties binnengestapt waarbij elke belanghebbende in de ruimte een compleet andere film in zijn hoofd afspeelde, en niemand de moeite had genomen om de notities te vergelijken.

De ingenieurs dachten dat AI hun banen kwam overnemen. Dus saboteerden ze het, werkten ze eromheen of veinsden ze enthousiasme dat ze niet voelden. De bedrijfsafdeling dacht dat het magie was — je beschrijft een probleem en er verschijnt een oplossing. De leidinggevenden zagen een vermindering van het aantal medewerkers op een spreadsheet voordat er ook maar één regel code was geschreven. Drie groepen, drie compleet verschillende definities van hoe succes eruitzag, en geen van hen praatte met de anderen.

Geen van hen had gelijk, en ze hadden allemaal gelijk. AI verandert wel degelijk wat ingenieurs doen. Het kan dingen die als magie aanvoelen, totdat dat niet meer zo is. En ja, de organisatiestructuur verandert. Maar de volgorde is belangrijk.

CTO's moeten verwachtingen op elkaar afstemmen. Voordat je één enkele tool implementeert, breng je alle belanghebbenden bij elkaar en stem je af over één vraag: "Wat verandert dit en wat verandert dit niet?"

De ingenieurs die bang zijn, moeten horen dat hun domeinexpertise juist waardevoller is geworden, niet minder waardevol. De bedrijfsafdeling moet begrijpen dat er voor magie nog steeds engineering nodig is. En de leidinggevenden moeten begrijpen dat de besparingen na de investering komen, niet in plaats daarvan.

Soms is de juiste stap om te stoppen, de reikwijdte te beperken, twee groepen mensen het over iets kleins eens te laten worden, ze te laten zien dat het werkt en van daaruit verder te groeien. Afgedwongen afstemming houdt geen stand. Afstemming die je verdient door een kleine gezamenlijke overwinning wel.

Waarom ontslagen door AI je beste wervingskans zijn

Begin bij het werven met de mensen die zojuist door de AI-golf zijn verdrongen.

De Big 4-bedrijven automatiseerden zich een weg door functies op het gebied van beoordeling, controle en naleving. Dit zijn mensen die gedurende hun loopbaan precies het beoordelingsvermogen, de patroonherkenning en de domeinexpertise hebben ontwikkeld die AI-governance vereist. Ze weten hoe ze kunnen ontdekken wat er mis is in een complex systeem. Ze weten hoe ze dat moeten documenteren, escaleren en er beheersmaatregelen omheen moeten bouwen.

Dat is geen toeval! Dat is de functieomschrijving. De ironie is dat de sector zijn eigen beste kandidatenpool heeft gecreëerd. Ga ze zoeken.

Waarom SME's de waardevolste bedrijfsmiddelen van een CTO zijn

De hele sector is opgebouwd rond teamgrootte, sprintvelocity, resourceallocatie, organogrammen en wervingsplannen. De onderliggende aanname is dat je vanaf een bepaald complexiteitsniveau absoluut mensen nodig hebt. Meer modules betekent meer ingenieurs en natuurlijk betekenen meer producten meer teams. Dat is geen mening, zo heeft de rekensom altijd gewerkt — totdat AI de vergelijking vernietigde.

En dat zou elke CTO die zijn loopbaan heeft opgebouwd rond de rol van teamleider moeten beangstigen.

Dat wil niet zeggen dat het team geen waarde heeft. Integendeel. De mensen die nu in die functies werken — vooral degenen van wie we dachten dat ze "overhead" waren, zoals bedrijfsanalisten en productmanagers — zijn ongelooflijk waardevol. Omdat je SME's nodig hebt.

Zoek ze. Elke organisatie heeft ze. Dit zijn de mensen in de bedrijfsafdeling die precies weten hoe alles werkt, die al jaren een constante bron van ergernis voor je zijn en om meer hebben gevraagd dan je kon leveren. Leid ze op in het werken met AI. Geef ze de tools. Ga uit de weg, behalve om ze te coachen en ervoor te zorgen dat ze zich aan de kaders houden.

Een SME die de bedrijfsafdeling diepgaand begrijpt en AI beheerst, is geen ervaren gebruiker. Dat is een katalysator. Daar vindt de echte transformatie plaats, niet in je datacenter en niet in je architectuurbeoordelingsraad. In de handen van de mensen die daadwerkelijk weten wat de bedrijfsafdeling nodig heeft. Bouw een relatie op tussen die mensen en iets als Claude Code.

Ik gaf mijn vrouw voor Kerstmis een jaar Claude cadeau. Ze is geen ontwikkelaar. Ze gebruikte het om een bedrijf op te bouwen. Dat gebeurt wanneer je het juiste hulpmiddel in handen geeft van iemand die precies weet welk probleem diegene probeert op te lossen. Stel je nu voor dat dit binnen je organisatie gebeurt met vijftig mensen die je bedrijfsafdeling door en door kennen. Dat is geen pilotprogramma, dat is een bedrijfsrevolutie.

Hoe de sector de verkeerde vragen stelt

En dat vertelt me alles over hoe de sector dit probleem nog steeds benadert.

AI wordt nog steeds gezien als een gesprek over tools, workflows en snelheid. Dat is de verkeerde benadering. Gegevensbeheer, beveiliging en toezicht zijn wat IT wordt. Niet morgen, maar tegen 2030.

Elke andere functie waarvoor je momenteel personeel inzet — zoals levering, ontwikkeling, operationeel beheer en ondersteuning — wordt overgenomen of geëlimineerd door AI-ondersteunde zakelijke gebruikers en SME's die het bedrijf door en door kennen. Wat overeind blijft, is het werk dat niet kan worden gedelegeerd aan een agent of een getrainde SME: ervoor zorgen dat je gegevens betrouwbaar zijn, je systemen veilig zijn en je mensen en agents binnen beschermende grenzen opereren.

De organisaties die in 2027 nog steeds vragen "Hoe kunnen we AI sneller gebruiken?" zullen frontaal botsen met de organisaties die vandaag vroegen "Hoe kunnen we het beter besturen?".

Ik weet liever bij welke van de twee ik hoor.

Volg mee

Je kunt het werk van Christopher Kouzios volgen op LinkedIn. Beluister ook de EMZ-podcast.

Er volgen nog meer expertinterviews op The CTO Club!