73.000 'slimme' meters vielen in één nacht uit — en het onthulde alles wat er mis is met hoe we infrastructuur-AI bouwen

Een vriend die de operationele leiding heeft bij een middelgroot waterbedrijf belde me op een zaterdagochtend. Niet om bij te kletsen — om zijn hart te luchten. Zijn team had net ontdekt dat een firmware-update die de week ervoor naar hun slimme-meterpark was uitgerold, stilletjes de factuurgegevens van duizenden accounts had beschadigd. Op het dashboard zagen de meters er prima uit. Overal groene lampjes. Maar de cijfers die het facturatiesysteem binnenstroomden, waren verkeerd, en niemand merkte het op totdat een golf van klachten van klanten binnenkwam.

"De leverancier zegt dat het een bekend probleem is," vertelde hij me. "Ze werken aan een patch."

Ik vroeg hoe lang de meters al foute gegevens verstuurden. Hij aarzelde. "We denken ongeveer negen dagen."

Dat gesprek bleef me bij — niet omdat de technologie faalde, maar vanwege hoe onzichtbaar de storing was. Dit waren geen meters die offline gingen. Het waren meters die vrolijk bleven doordraaien en gegevens verstuurden die plausibel leken maar stilzwijgend verkeerd waren. En toen ik het draadje van slimme-meterstoringen in heel Noord-Amerika en het Verenigd Koninkrijk begon uit te trekken, besefte ik dat de zaterdagochtendcrisis van mijn vriend een voetnoot was in een veel groter verhaal.

De nacht waarin 73.000 meters stilvielen

In Plano, Texas, had de stad $10,2 miljoen uitgegeven aan 87.000 slimme watermeters van Aclara Technologies, in de verwachting dat ze twintig jaar mee zouden gaan. Tegen 2023 gingen de batterijen voortijdig kapot. De oplossing van de leverancier? Een firmware-update op afstand, in november 2024 uitgerold om het stroomverbruik te optimaliseren.

Die update maakte 73.000 meters onbruikbaar.

Geen "verminderde prestaties." Geen "sporadische storingen." De elektronische transmissiesystemen stopten simpelweg met werken. Plano — een stad van bijna 300.000 inwoners in de metropoolregio Dallas-Fort Worth — moest 20 tijdelijke meteropnemers inhuren en terugvallen op het lopen van routes van deur tot deur. Kosten: $765.000 over twee jaar, alleen al voor het handwerk.

Ik blijf terugkomen op de bittere ironie hiervan. De firmware moest het batterijprobleem oplossen. In plaats daarvan veranderde het een lokaal hardwareprobleem in een netwerkbrede ineenstorting. Ik ben dit de Firmware-Batterij-Paradox gaan noemen — de software die is ontworpen om de levensduur van de hardware te verlengen, wordt het belangrijkste mechanisme van haar falen.

De software die is ontworpen om de levensduur van hardware te verlengen, wordt vaak het belangrijkste mechanisme van haar falen.

En Plano staat niet alleen. Toronto verloor 470.000 zenders door vroegtijdige degradatie — $5,6 miljoen aan initiële herstelkosten. Memphis Light, Gas and Water kampte met een systemisch uitvalpercentage van 8% in hun slimme-meterpark en reserveerde $9 miljoen voor reparaties. In het Verenigd Koninkrijk zijn sinds toezichthouders er aandacht aan begonnen te besteden meer dan 900.000 slimme meters gerepareerd of vervangen.

Ik heb dieper op de technische architectuur achter deze storingen ingegaan in de interactieve versie van ons onderzoek, maar het patroon is overal waar ik kijk consistent: nutsbedrijven gaven miljarden uit aan het digitaliseren van hun netten, en de "slimme" infrastructuur begeeft het sneller dan de mechanische meters die ze verving.

Waarom sterven slimme meters jong?

Toen mijn team de grondoorzaken begon te analyseren, verwachtten we slordige productie of goedkope componenten aan te treffen. De werkelijkheid was verontrustender.

Slimme meters zijn geen eenvoudige meetapparaten. Het zijn genetwerkte computers — geïntegreerde processoren, edge-AI-chips, beveiligde communicatieprotocollen, flashgeheugen voor gegevensopslag. En net als elke computer zijn ze onderhevig aan faalmodi die mechanische meters nooit hadden.

Het probleem met het flashgeheugen is bijzonder verraderlijk. Slimme meters gebruiken NAND-flash om firmware en diagnostische logs op te slaan. Elke schrijfbewerking genereert verouderde data die wordt gewist via een proces genaamd garbage collection, dat de geheugencellen fysiek doet verslijten. Als de embedded bestandssystemen niet geoptimaliseerd zijn — en in veel geïnstalleerde meters zijn ze dat niet — begint de opslag jaren voor het veronderstelde einde van de levensduur van het apparaat gegevens te beschadigen.

Dit is waar het zaterdagochtendtelefoontje van mijn vriend meer betekenis krijgt. De corruptie is vaak stil. De meter geeft geen foutmelding. Hij gaat niet offline. Hij begint gewoon licht verkeerde cijfers te versturen. Tegen de tijd dat iemand het opmerkt, heb je negen dagen — of negen maanden — aan foutieve factuurgegevens en een vertrouwensprobleem met klanten dat geen enkele firmware-patch kan verhelpen.

Dan is er de edge-case-crisis. De softwarecomplexiteit in slimme meters is de afgelopen jaren ongeveer verdubbeld, maar de testmethodologieën hebben geen gelijke tred gehouden. Een firmware-update werkt perfect in het lab, maar rol hem uit naar een meter met een licht gedegradeerde batterij in een landelijk gebied met zwakke signaalsterkte, en je krijgt Plano.

Eén detail uit het onderzoek dat me echt verontrustte: moderne slimme meters hebben een ingebouwde "UIT"-schakelaar op afstand voor administratief gemak. Als een logische fout in de firmware die schakelaar per ongeluk op grote schaal activeert, kijk je niet naar factuuronnauwkeurigheden — dan kijk je naar miljoenen huizen die tegelijkertijd zonder stroom komen te zitten.

Wat gebeurt er wanneer toezichthouders gaan tellen?

De Britse energietoezichthouder Ofgem vond dat ze genoeg hadden gezien. Vanaf februari 2026 handhaven ze Guaranteed Standards of Performance die automatische betalingen van £40 aan klanten verplichten wanneer niet aan de servicenormen voor slimme meters wordt voldaan. Langer dan zes weken wachten op een installatieafspraak? Automatische betaling. Installatie mislukt omdat de leverancier zonder de juiste apparatuur kwam opdagen? Automatische betaling. Meterstoring gemeld en geen oplossingsplan binnen vijf werkdagen? Automatische betaling.

Dit is geen tik op de vingers. Voor een nutsbedrijf met miljoenen klanten en een park van verouderende slimme meters loopt de rekensom razendsnel angstaanjagend op. De nalevingsdruk heeft in het Verenigd Koninkrijk al geleid tot de reparatie van meer dan 900.000 eerder niet-werkende meters.

Ik denk dat de zet van Ofgem iets groters aankondigt dan één toezichthouder die streng wordt. Het is de formalisering van een principe dat vanaf het begin duidelijk had moeten zijn: als je "slimme" infrastructuur uitrolt, ben je verantwoordelijk om die slim te houden. Het tijdperk van hardware installeren, weglopen en het beste hopen is voorbij.

Als je "slimme" infrastructuur uitrolt, ben je verantwoordelijk om die slim te houden. Het tijdperk van installeren-en-vergeten is voorbij.

Voor nutsbedrijfsleiders die dit lezen, is de implicatie hard. De kosten van het onderhouden van een niet goed functionerende meter — in de vorm van boetes van toezichthouders, handmatig herstel, klantverloop en factuurgeschillen — overtreffen nu de kosten van het implementeren van realtime, AI-gestuurde diagnostiek. De economische verhoudingen zijn omgeslagen.

"Gebruik gewoon GPT" — het advies waar ik 's nachts van wakker lig

Nadat ik enkele eerste bevindingen over de kwetsbaarheid van slimme meters had gepubliceerd, had ik een gesprek met een potentiële investeerder waar ik nog steeds aan denk. Hij had de data over firmwarestoringen gezien, was het ermee eens dat het probleem echt was, en zei vervolgens: "Bouw dan een ChatGPT-wrapper die metergegevens analyseert. Lever hem binnen drie maanden op."

Ik probeerde uit te leggen waarom dat niet zou werken. Hij onderbrak me. "Elke AI-startup zegt dat ze aangepaste modellen moeten bouwen. De meeste denken er gewoon te veel over na."

Ik begrijp zijn logica. De markt wordt overspoeld met bedrijven die in wezen dunne interfaces zijn bovenop de API's van OpenAI of Anthropic — wat de sector "LLM-wrappers" noemt. Sommige daarvan zijn oprecht nuttig voor toepassingen met lage inzet. Maar voor kritieke infrastructuur? De aanpak is fundamenteel gebrekkig, en ik moet uitleggen waarom.

Waar gaan de gegevens naartoe?

Wanneer je een publieke AI-API gebruikt, verlaten je gegevens je netwerk en belanden ze op de servers van een derde partij. Voor een nutsbedrijf omvatten die gegevens de netarchitectuur, verbruikspatronen van klanten, propriëtaire firmwarecode en mogelijk geclassificeerde kwetsbaarheden in de infrastructuur. Dit is geen hypothetisch risico — het is blootstelling aan de Amerikaanse CLOUD Act en aan welk databewaarbeleid de API-aanbieder dit kwartaal toevallig ook hanteert.

Ik noem dit Security Theater. De tool ziet eruit en voelt aan als een private bedrijfsapplicatie. Op het dashboard staat het logo van jouw bedrijf. Maar de backend is een publieke voorziening, en je meest gevoelige operationele gegevens stromen door de infrastructuur van iemand anders.

Kan een generiek model jouw net begrijpen?

Een publieke LLM heeft het internet gelezen. Het weet in abstracte zin wat een slimme meter is. Wat het niet weet, is de specifieke firmwareversie die draait op jouw Aclara-meters in het noordoostelijke kwadrant, de onderhoudsgeschiedenis van de transformatoren die die buurt voeden, of het feit dat jouw verouderde facturatiesysteem decimalen afkapt op een manier die kleine meetfouten maskeert.

Het contextvenster van een publieke API vergeet de nuance van jouw specifieke infrastructuur. Het kan niet de binaire analyse uitvoeren die nodig is om te verifiëren of een firmware-update veilig is voor een bepaalde hardwarerevisie die is uitgerold in een bepaalde klimaatzone. Het daarom vragen is als een toerist naar de weg vragen — ze klinken misschien zelfverzekerd, maar ze weten eigenlijk niet waar ze heen gaan.

Wat gebeurt er wanneer de API verandert?

Dit is het onderdeel waar nutsbedrijfsleiders zelden over nadenken totdat het te laat is. Als jouw "AI-oplossing" een promptlaag is bovenop het model van iemand anders, ben je afhankelijk van hun prijzen, hun modelupdates, hun uptime en hun zakelijke beslissingen. Wanneer OpenAI hun API-structuur wijzigt of een modelversie uitfaseert, gaat jouw tool voor kritieke infrastructuur kapot totdat iemand de prompts herschrijft.

Kritieke infrastructuur kan niet afhankelijk zijn van de bedrijfscontinuïteit van de API-prijspagina van een Silicon Valley-startup.

Hoe Deep AI er werkelijk uitziet

Na dat gesprek met de investeerder was ik een week gefrustreerd. Daarna besteedde ik drie maanden aan het bouwen van wat volgens mij het werkelijke antwoord is.

Bij Veriprajna verkopen we geen API-sleutels door. We bouwen geen wrappers. We rollen de volledige AI-inferentiestack uit — engines zoals vLLM, Text Generation Inference en BentoML — rechtstreeks op de eigen infrastructuur van de klant. Hun Kubernetes-clusters. Hun bare-metal-GPU's. Hun Virtual Private Cloud.

De eerste keer dat we een zero-egress-VPC configureerden voor een klant in de nutssector — wat betekende dat het netwerk fysiek zo was geconfigureerd dat data niet hun omgeving kon verlaten, zelfs als iemand iets verkeerd zou configureren — keek een van hun beveiligingsengineers naar het architectuurdiagram en zei: "Dit is de eerste keer dat een AI-leverancier me niet heeft gevraagd om een uitzondering te maken op ons databeleid." Dat moment vertelde me dat we op de goede weg zaten.

Een semantisch brein bouwen

Het contextprobleem — datgene wat generieke LLM's nutteloos maakt voor echt infrastructuurwerk — lossen we op met wat ik zie als een "semantisch brein." We nemen de propriëtaire documenten van het nutsbedrijf in: technische handleidingen, historische onderhoudsrapporten, firmwarebroncode, incidentregistraties. Dat alles wordt geïndexeerd in lokale vectordatabases zoals Milvus of Qdrant en verlaat nooit de omgeving van de klant.

Maar hier is het deel waar ik het trotst op ben: het systeem respecteert bestaande toegangsrechten. Als een medewerker geen toestemming heeft om een document in SharePoint te bekijken, zal de AI die informatie niet ophalen om diens vraag te beantwoorden. We hebben beveiliging er niet als bijzaak op vastgeschroefd — we hebben de intelligentielaag zo gebouwd dat die de bestaande beveiligingshouding van de organisatie erft.

De laatste loodjes van nauwkeurigheid

We nemen open foundation-modellen zoals Llama 3 en fine-tunen ze op het specifieke corpus van het nutsbedrijf met technieken als LoRA (Low-Rank Adaptation). Het resultaat is een op maat gemaakt model dat de nomenclatuur van de klant begrijpt, hun verouderde systemen, hun operationele eigenaardigheden. In onze tests verhoogt deze domeinspecifieke fine-tuning de nauwkeurigheid voor gespecialiseerde taken met maximaal 15% ten opzichte van het basismodel.

Die 15% klinkt misschien marginaal. Dat is het niet. Bij firmwareverificatie is het verschil tussen 85% en 100% nauwkeurigheid het verschil tussen het onderscheppen van een gevaarlijke update en die 73.000 meters onbruikbaar laten maken.

Hoe vang je een firmwarebug op voordat die het veld in gaat?

Dit is de vraag die me dreef na het bestuderen van de ramp in Plano. De firmware-update die die meters om zeep hielp, was niet kwaadaardig. Hij was niet geschreven door incompetente ingenieurs. Hij was gewoon niet getest tegen het volledige scala aan praktijkomstandigheden die hij zou tegenkomen.

We hebben hiervoor een pipeline gebouwd. Het begint met binaire identificatie — met tools als EMBA en Firmwalker om firmwarebestandssystemen te extraheren en analyseren, zelfs wanneer broncode niet beschikbaar is. Vervolgens decompileren we de binary met Ghidra, en onze private LLM analyseert de gedecompileerde code op logicafouten, onveilige praktijken en potentiële kwetsbaarheden.

Maar het onderdeel dat veranderde hoe ik over firmwareveiligheid denk, is de digital-twin-aanpak. Firmware testen op fysieke apparaten in het veld is traag, duur en riskant. In plaats daarvan bouwen we gedetailleerde virtuele replica's van slimme woningen en netsegmenten, en zetten we vervolgens AI-agents in die reinforcement learning gebruiken om met deze digital twins te interacteren — systematisch op zoek naar de edge cases die menselijke testers missen.

In ons onderzoek vond deze methode kwetsbaarheden 38% sneller dan willekeurige testaanpakken. Voor de volledige technische uiteenzetting van de firmwareverificatiepipeline en de digital-twin-methodologie, raad ik je aan het paper te lezen — maar het cruciale inzicht is dit: we kunnen nu de omstandigheden simuleren die de storing in Plano veroorzaakten voordat de update wordt uitgerold.

We kunnen nu de omstandigheden simuleren die catastrofale firmwarestoringen veroorzaakten, voordat de update ooit het veld in wordt uitgerold.

Van reactief naar voorspellend: wat verandert er wanneer AI het net bewaakt

De traditionele benadering van onderhoud bij nutsbedrijven is ofwel reactief (repareer het wanneer het kapotgaat) ofwel gepland (inspecteer het elke X maanden, of het nu nodig is of niet). Beide zijn duur en beide missen de storingen die er het meest toe doen — de trage, stille degradaties die zich pas aankondigen wanneer ze al schade hebben veroorzaakt.

Deep AI-modellen die getraind zijn op hoogfrequente sensordata leren hoe "normaal" eruitziet voor elk apparaat, elke transformator, elk netsegment. Wanneer iets afwijkt — een ongebruikelijk trillingspatroon, een temperatuurschommeling die niet bij het weer past, een park van meters die allemaal tegelijk een verhoogde communicatielatentie vertonen — signaleert het systeem dat voordat het een crisis wordt.

Er was een moment tijdens onze vroege tests waarop het anomaliedetectiesysteem een groep meters signaleerde die allemaal een subtiele toename in responslatentie vertoonden. Niets dramatisch — misschien 15 milliseconden trager dan de basislijn. Mijn team discussieerde of dit ruis was of een signaal. Onze ingenieur betoogde dat het aan de omgeving lag — temperatuurgerelateerd. Ik drong aan op verder onderzoek. Het bleek een vroege indicator te zijn van degradatie van het flashgeheugen in een specifieke batch apparaten. Onaangepakt zouden die meters binnen enkele maanden gegevens zijn gaan beschadigen.

Dat is het soort vondst dat de hele investering rechtvaardigt. En de cijfers bevestigen het: van AI-gestuurd voorspellend onderhoud is aangetoond dat het infrastructuurstoringen met 73% vermindert, onderhoudskosten met 18-25% verlaagt en de levensduur van activa met maximaal 40% verlengt.

Het systeem gebruikt ook explainable AI — wanneer het een anomalie signaleert, toont het de menselijke operator waarom, met behulp van visualisatietools zoals GradCAM. De operator kan het oordeel van de AI verifiëren, corrigeren of overrulen. Die feedbacklus betekent dat het systeem na verloop van tijd slimmer wordt, waardoor er minder valse positieven zijn en het soort institutionele kennis wordt opgebouwd dat doorgaans alleen in de hoofden van senior ingenieurs zit die vijf jaar van hun pensioen af zijn.

En de ROI dan?

Mensen brengen altijd de kosten in van het uitrollen van private AI-infrastructuur versus het simpelweg gebruiken van een API. Het is een terechte vraag. Je eigen GPU-clusters draaien en je eigen modellen onderhouden is niet goedkoop.

Maar bedenk wat het alternatief kost. Plano: $765.000 voor handmatige meteropnemers, plus de oorspronkelijke investering van $10,2 miljoen die nu aanzienlijk in waarde is verminderd. Memphis: een reparatiefonds van $9 miljoen. Toronto: $5,6 miljoen en het loopt op. Britse nutsbedrijven: de cumulatieve kosten van 900.000 metervervangingen plus de boetes van toezichthouders die op het punt staan te beginnen.

Sectoren rapporteren gemiddelde uitvalkosten van $125.000 per uur. Een reductie van 30-50% in downtime betaalt niet alleen de AI terug — het transformeert het financiële profiel van het nutsbedrijf. Als je daar de uitgestelde kapitaaluitgaven bij optelt door de levensduur van activa met 40% te verlengen, een reductie van 28% in vertragingen in de toeleveringsketen van componenten, en een reductie van 40% in veiligheidsincidenten, dan laat de ROI-berekening geen twijfel bestaan.

De vraag is niet of nutsbedrijven zich soevereine AI-infrastructuur kunnen veroorloven. De vraag is of ze zich nog een Plano kunnen veroorloven.

De echte slotgracht voor een nutsbedrijf is niet het AI-model zelf — Llama 3 kun je gratis downloaden. De slotgracht is de diepe integratie met propriëtaire data, de domeinspecifieke fine-tuning, de institutionele kennis die is vastgelegd in een systeem dat draait op infrastructuur die jij beheert. Dat is een activum dat na verloop van tijd in waarde stijgt. Een API-abonnement is een kostenpost die je kan worden afgenomen.

Het net waar we naartoe bouwen

Nu naar verwachting het aantal IoT-apparaten tegen 2026 de 30 miljard overschrijdt, verdwijnt het complexiteitsprobleem niet. Het versnelt. De volgende grens — en waar mijn team actief naartoe bouwt — zijn agentic AI-workflows: systemen die niet alleen anomalieën signaleren, maar ook actie ondernemen. Automatisch een gecompromitteerd IoT-apparaat in quarantaine plaatsen. Transformatorparameters in realtime aanpassen op basis van voorspelde belastingpatronen. Firmware-rollbacks uitvoeren op het moment dat een update tekenen vertoont van problemen.

Edge AI zal intelligentie nog verder naar buiten duwen — slimme meters die functioneren als micro-beslismachines, die lokale anomaliedetectie draaien met een latentie van minder dan 10 milliseconden, en beslissingen nemen zonder te wachten op een heen-en-weerreis naar de cloud.

Maar niets van dit alles werkt als het fundament verkeerd is. En op dit moment is bij de meeste nutsbedrijven het fundament verkeerd. Ze draaien 21e-eeuwse infrastructuur op 20e-eeuwse onderhoudsparadigma's, en wanneer ze naar AI grijpen, pakken ze de goedkoopste, meest gemakkelijke optie — een wrapper rond de intelligentie van iemand anders — in plaats van soevereine capaciteit op te bouwen.

De storingen in Plano, Toronto, Memphis en overal in het Verenigd Koninkrijk zijn geen technische haperingen. Het zijn het voorspelbare resultaat van een systemische mismatch tussen de complexiteit van moderne infrastructuur en de tools die we gebruiken om die te beheren. Elk nutsbedrijf dat slimme meters uitrolt zonder te investeren in de intelligentie om ze werkelijk te besturen, bouwt een systeem dat is ontworpen om te falen op manieren die het niet kan detecteren.

De keuze waar nutsbedrijfsleiders voor staan, is niet die tussen AI en geen AI. Dat debat is voorbij. De keuze is die tussen het huren van intelligentie van aanbieders die geen belang hebben bij de betrouwbaarheid van jouw net, of het opbouwen van soevereine capaciteiten die je operationele data omzetten in je meest waardevolle activum. Een van die paden leidt naar de volgende Plano. Het andere leidt naar een net dat werkelijk zo slim is als we blijven beloven.