Hoe je AI veilig de controle geeft over een zware bedrijfsaansluiting

Dat principe vraagt om drie dingen: een systeem dat onder alle omstandigheden onder controle blijft, een doordachte keuze in hoe je het algoritme traint, en een architectuur die schaalt naar honderden locaties zonder dat maatwerk de overhand krijgt. We beginnen bij het belangrijkste: de controle. 

De drie controlelagen

Een veelgehoorde zorg bij Deep Reinforcement Learning (DRL) is het black box karakter: het algoritme krijgt data als input en levert een actie als output, maar de logica achter deze acties is van buitenaf lastig te doorgronden. Wat als het model een beslissing neemt die niemand begrijpt? Of erger, die de netaansluiting in gevaar brengt?

Wij hebben de architectuur rondom drie controlelagen gebouwd die dit risico structureel adresseren.

Verklaarbaarheid

Een DRL-model is in de praktijk geen absolute black box, maar volledige transparantie is ook een illusie. Voor individuele beslissingen kunnen we achterhalen welke inputdata waarschijnlijk het zwaarste meetelden. Dat geeft geen wiskundig bewijs, maar wel een goede schatting. Genoeg voor onze engineers om te begrijpen waarom een bepaalde laad- of ontlaadstrategie is gekozen. 

Voor langetermijnstrategieën is dat moeilijker. Waarom het model over weken gemeten de batterij anders inzet dan een domeinexpert-algoritme zou doen, ontstaat in de loop van miljoenen trainingsstappen en is niet simpelweg te herleiden tot één oorzaak. 

Harde begrenzing

De meest kritieke laag is de begrenzing van de AI. Het algoritme heeft de vrijheid om te handelen, maar uitsluitend binnen strak gedefinieerde grenzen. Op de achtergrond draaien voorspellingsmodellen mee als een continu veiligheidsnet. Zij berekenen de absolute grenzen waar de AI binnen moet blijven, op basis van twee harde randvoorwaarden:

• Minimale reservecapaciteit: Het systeem reserveert te allen tijde voldoende batterijcapaciteit om verwachte én onverwachte vermogenspieken op te vangen.
• Netaansluiting: Het systeem werkt op kwartierbasis: voor elk komend kwartier wordt eerst berekend hoeveel vermogen er ná het basisverbruik nog beschikbaar is binnen het gecontracteerde vermogen. Het systeem mag alleen acties voorstellen die binnen het resterende vermogen passen. Iedere voorgestelde laad- of ontlaadactie wordt eerst doorgerekend voordat hij wordt uitgevoerd. Past hij niet, dan wordt hij geblokkeerd. De overschrijding kan dus niet gebeuren omdat het systeem hem achteraf corrigeert, maar omdat hij vooraf wiskundig wordt uitgesloten.

Kiest de AI een strategie die deze parameters schendt, dan blokkeert het veiligheidsnet de actie onmiddellijk. Onveilige beslissingen bereiken de fysieke infrastructuur nooit.

Continue benchmarking

Een DRL-model neemt soms acties die op het eerste gezicht niet intuïtief lijken, maar op de lange termijn een betere strategie blijken te zijn dan de voor de hand liggende keuze. Om het model de ruimte te geven die waarde te bewijzen, benchmarken wij de prestaties continu tegen domeinexpert-algoritmes (de rule-based logica uit deel 1) die parallel blijven meedraaien. Na een vaste periode, bijvoorbeeld twee weken, vergelijken we de uitkomsten.

Snel leren op nieuwe locaties

Met de controle op zijn plek komt de tweede ontwerpkeuze: hoe trainen we het model? Die keuze bepaalt direct of het systeem werkbaar is op één locatie of op honderd. Binnen DRL bestaan twee benaderingen. 

• Een model-free aanpak leert puur door te experimenteren. De agent probeert miljoenen acties uit in een virtuele omgeving en ontdekt op basis van directe feedback wat werkt. Die flexibiliteit heeft een prijs: de methode is extreem data-intensief. Om betrouwbare patronen te herkennen zijn jarenlange, gedetailleerde historische datasets nodig op kwartierbasis, per locatie.
• Een model-based aanpak combineert die virtuele omgeving met een intern model van de omgeving. We geven het algoritme vooraf mee wat de consequenties van een actie zijn: dat ‘laden’ de batterij vult én direct gelijkstaat aan stroom inkopen, dat een ontlaadactie de beschikbare bufferruimte verlaagt. Hierdoor hoeft de agent deze fundamentele relaties niet zelf uit de data af te leiden. Het leert sneller, heeft minder historische data nodig en kan simuleren wat de gevolgen van een actie zijn vóór die actie wordt uitgevoerd. 

In de praktijk is dataschaarste op nieuwe locaties een structureel probleem. Op een nieuwe locatie ontbreekt vaak jarenlange, gedetailleerde verbruiksdata op kwartierbasis. Waar een model-free aanpak hier vastloopt, bereikt model-based RL met aanzienlijk minder data een werkend resultaat. Het bouwen en onderhouden van een accuraat model is complex en domeinspecifiek. Maar voor energiesystemen, waar de fysieke grenzen bekend zijn, is dat een beheersbaar probleem.

De keuze voor model-based lost één vraagstuk op. Een tweede dilemma blijft: hoe schaal je dit naar honderden locaties zonder voor elke locatie opnieuw te beginnen?

Schalen zonder in te leveren op prestaties

Naast de keuze voor leermethode is de architectuur van het systeem bepalend voor de effectiviteit op de lange termijn. Als een EMS op tientallen of honderden bedrijfslocaties draait, ontstaat er een ontwerpdilemma:

• Individuele modellen per klant: presteren uitstekend op maatwerk, maar de training en het onderhoud zijn tijdrovend. Wat het algoritme leert op locatie A, wordt niet automatisch toegepast op locatie B.
• Eén universeel model: legt verbanden over alle locaties heen en vergt minder onderhoud, maar presteert suboptimaal op individueel niveau. Elke aanpassing voor één specifieke situatie beïnvloedt direct het gedrag op alle andere locaties. 

Wij lossen dit op door het model per locatie de juiste context mee te geven. Eén model leert generieke patronen, en krijgt per locatie informatie mee als aansluitcapaciteit, productieprofiel en verbruikspatroon. Zo past het diezelfde geleerde patronen toe op de specifieke situatie. Naarmate we de modellen complexer maken, voorzien we modelfamilies: varianten voor specifieke locatietypen, zoals zware netcongestie of overcapaciteit aan zonnepanelen. Nieuwe locaties profiteren dan direct van wat er binnen hun categorie al geleerd is. 

Waar AI wel en niet thuishoort

Modelfamilies werken omdat ze leervermogen toepassen op de plek waar leren waarde toevoegt: het herkennen van patronen in onzekere data: energieprijzen, weer, vraag. Wat ze niet doen, is leren wat de specifieke installatie-opbouw van een klant is. Die kennis bouw je niet op uit trial-and-error; die ken je vooraf, of je voert metingen uit en legt het vast.

Dat is een principe dat het hele ontwerp doortrekt. AI is uitstekend in onzekerheid: prijsprognoses, vraagvoorspelling, marktstrategie tussen day-ahead, intraday en onbalans. Voor zekerheden zoals fysieke grenzen, aansluitingscontracten en topologie leunen we op de domeinexpert. Niet omdat AI dat niet zou kunnen leren, maar omdat het AI-maatwerk dat dan ontstaat duur en niet-schaalbaar is. 

Conclusie

De combinatie van drie controlelagen, model-based leren en modelfamilies maakt het mogelijk om een zelflerend systeem in te zetten dat rendement optimaliseert zonder de bedrijfszekerheid in gevaar te brengen. De AI leert, maar binnen grenzen die wij definiëren, en alleen op plekken waar leren daadwerkelijk waarde toevoegt. Dat is voor ons het verschil tussen AI als marketingterm en AI als betrouwbare operationele technologie.