AI voor CTO's: opleverdata, cloudkosten, pentesttriage en technische schuld, beantwoord vanuit je eigen bestanden

Sales wil een datum voor de nieuwe module en je velocity is drie sprints stabiel. Genoeg om een datum te noemen, bij lange na niet genoeg om hem te verdedigen, want datums sneuvelen veel vaker aan scope dan aan velocity, en het echte sliprisico zit in twee integratietickets waarvan je de afhankelijkheden zou moeten gaan nalezen. Het gevaar is niet dat je ernaast zit. Het gevaar is dat je op dinsdag toezegt en in oktober merkt dat je een getal hebt toegezegd in plaats van een scope.

Die post loopt elke maand op en het eerlijke antwoord op "waar gaat dat heen" kost een middag in Cost Explorer die er nooit komt. Je bent daarin niet de enige: Flexera's State of the Cloud-rapport 2026, gebaseerd op ruim 750 cloudbeslissers, zette de zelf gerapporteerde verspilde cloud-uitgaven op 29%, de eerste stijging in vijf jaar, met kostenbeheersing als topuitdaging voor 85%. Dat cijfer is context voor het gesprek, geen besparing die iemand je kan beloven. Wat je nodig hebt is je eigen kostendrijvers op volgorde, met de zombieresource en de verlopen reserveringen allebei bij naam.

Vrijdag landt er een pentest met negen criticals en maandag zit de board klaar. Het risico is echt: Verizon's Data Breach Investigations Report 2025, over ruim 22.000 incidenten en 12.195 bevestigde datalekken, vond dat het misbruiken van kwetsbaarheden als eerste toegangsweg met 34% steeg tot 20% van de lekken, en dat lekken waarbij een derde partij betrokken was verdubbelden naar 30%. Daaronder ligt het schuldgesprek dat je blijft uitstellen; McKinsey's onderzoek zette de eigen schattingen van CIO's voor technische schuld op 20% tot 40% van de waarde van het volledige technologielandschap vóór afschrijving, een studie uit 2020 onder grote financiële en technologiebedrijven en dus geen benchmark voor jouw landschap. Allebei moeten ze vertaald worden naar geconcentreerd of verspreid, eigenaar en datum. Geen van beide overleeft het voorlezen van een lijstje severities.

Vraag of de datum verdedigbaar is en je krijgt de sprinthistorie, de twee tickets die het sliprisico dragen, en waaróm ze dat dragen (een externe API, een dependency zonder eigenaar), gelezen uit de Jira-export op je eigen schijf. Jij doet nog steeds de toezegging. Wat verandert is dat je een scope met een sluitingsdatum toezegt in plaats van een maand, en dat sales die twee tickets hoort in plaats van een datum waar ze je aan gaan houden.

Vraag waar het geld heen ging en je krijgt de kostenposten op volgorde in plaats van één nette schuldige: het idle cluster dat niemand heeft opgeruimd, plus de reserveringen die zijn verlopen en de opslag die nooit een lifecycle-regel kreeg. Een echte rekening is nooit één cluster, dus doet het antwoord ook niet alsof. Je krijgt een lijst die je kunt uitdelen, met per regel een naam en een datum, en een expliciete opmerking waar de export te grofmazig is om iets te kunnen zeggen.

Vraag wat je de board vertelt over de pentest en je krijgt de criticals geclusterd naar oorzaak, gekaderd als geconcentreerd of verspreid, met de slag om de arm erbij in plaats van eruit: reken op een regressieronde voordat je een grote dependency-bump afgerond noemt. Hetzelfde geldt voor schuld. Je krijgt het deel van het landschap dat je de meeste levertijd kost, en het zegt er eerlijk bij waar de bestanden geen cijfer onderbouwen. Je gaat naar binnen met een standpunt dat je bij vraag drie nog overeind houdt, niet met een slide die het bij vraag één goed doet.