Het patroon is herkenbaar: kritieke code die niemand intern begrijpt
Een netbeheerder laat een AI-module bouwen voor congestiebeheer of capaciteitsplanning. Het werkt. Het systeem draait. Na twee jaar is de leverancier overgenomen, gestopt of simpelweg niet meer bereikbaar. De interne engineers weten wat het systeem doet, maar niet hoe. Er is geen documentatie, geen overdrachtsdossier, geen testomgeving. De code is een erfstuk dat niemand durft aan te raken. Dit patroon zien we in energie en netbeheer vaker dan in andere sectoren, juist omdat de druk hoog is en de tijd kort: er moet snel iets gebouwd worden om de netcongestie aan te pakken, en de governance rond overdracht is een bijzaak. Totdat het een hoofdzaak wordt.
Waarom is dit risico groter in energie en netbeheer dan elders?
Drie factoren maken dit sector-specifiek gevaarlijk. Ten eerste zijn netbeheerders onderhevig aan wettelijke verplichtingen, zoals de Wet congestiemanagement en rapportageverplichtingen aan de ACM. Software die onderdeel is van die processen mag niet zomaar uitvallen of aangepast worden zonder dat iemand begrijpt wat er verandert. Ten tweede is de infrastructuur operationeel kritiek: een beslissingsondersteunend systeem dat stilstaat of foute output geeft, heeft direct gevolgen voor netbalans en leveringszekerheid. Ten derde wordt AI in dit domein steeds vaker ingezet voor voorspelling en automatische aanbevelingen, maar de eis van transparantie en menselijk toezicht staat haaks op software waarvan de interne werking niet is gedocumenteerd. Wie de code niet begrijpt, kan ook niet uitleggen waarom het systeem een bepaalde aanbeveling deed.
Wat gebeurt er concreet als de leverancier van je AI-software wegvalt?
In het beste geval heb je een werkende applicatie die je niet kunt aanpassen. Updates aan de omgeving, nieuwe data-invoer of regulatoire wijzigingen vereisen aanpassingen die niemand intern kan doorvoeren. Je bent afhankelijk van een nieuwe externe partij die de codebase opnieuw moet leren kennen, wat tijd en geld kost. In het slechtste geval heb je een systeem waarvan de licenties, API-koppelingen of cloudinfrastructuur zijn gebonden aan de verdwenen leverancier. Dan draait er niets meer. Voor een netbeheerder of energieleverancier betekent dat een terugval op handmatige processen, met alle risico's van dien voor capaciteitsbeheer, klantcommunicatie en compliance.
Wat houdt een goede overdrachts- en beheerstructuur concreet in?
Een robuuste overdrachtsstructuur bestaat uit vier concrete onderdelen. Eigendom van code en data: de broncode, de trainingsdata en de configuraties staan op infrastructuur van de opdrachtgever, niet van de leverancier. Documentatie op werkend niveau: niet een technisch rapport voor de la, maar documentatie waarmee een nieuwe engineer binnen redelijke tijd begrijpt hoe het systeem werkt, hoe het wordt gevoed met data, en hoe je het aanpast bij gewijzigde invoer. Testomgeving en deploymentpijplijn: een reproduceerbare manier om het systeem opnieuw te deployen, zodat je niet afhankelijk bent van de specifieke laptop of serveromgeving van de leverancier. En ten slotte kennisoverdracht aan interne medewerkers: minimaal twee mensen intern die hebben meegebouwd of aantoonbaar begrijpen hoe het systeem werkt. Dit klinkt als een basale projectafsluiting, maar in de praktijk is het bij AI-projecten in energie en netbeheer zelden volledig geregeld.
Wanneer bouw je het kernsysteem zelf opnieuw, en wanneer kies je voor een beheerlaag?
Niet elk energie- of netbeheerbedrijf hoeft zijn kernsystemen opnieuw te bouwen. Soms is een bestaand systeem goed genoeg en is het verstandiger om daar een beheerbare AI-laag omheen te bouwen, mits de eigendoms- en overdrachtsstructuur klopt. Maar als een organisatie merkt dat haar operationele kernprocessen draaien op software die intern niet begrepen wordt, niet gedocumenteerd is en aan een externe partij toebehoort, dan is dat een argument om het fundamenteler aan te pakken. Een kernsysteem dat volledig eigendom is van de organisatie, met code die intern begrepen en onderhouden kan worden, is weerbaarder dan een opeenstapeling van externe modules waarvan niemand de samenhang kent. De keuze hangt af van de complexiteit van het systeem, de omvang van de afhankelijkheid en de regulatoire eisen waaraan de organisatie moet voldoen.