Ga meteen naar de inhoud
Regelspotter: hoe AI regelgeving vertaalt naar concrete taken per gebouw
27 oktober 2026
Overzicht in de regels
Wie thuis een gasketel heeft, moet die om de twee jaar laten onderhouden door een erkend technicus. Bijna niemand denkt daaraan tot er iets misgaat. Breekt er brand uit, dan vraagt de verzekeraar al snel of je het onderhoudsattest kunt tonen.
In een kantoorgebouw staat er veel meer op het spel. Er staan tientallen toestellen en installaties met elk hun eigen regels. Het Facilitair Bedrijf beheert de gebouwen van de Vlaamse overheid. Eén gebouwbeheerder is er verantwoordelijk voor tot 60 gebouwen. Wat ontbreekt, is overzicht. Welke regel geldt voor welk gebouw? Wat moet er gebeuren? En kun je aantonen dat het gebeurd is?
Met die uitdaging trok Het Facilitair Bedrijf naar de Vlaanderen Hackathon 2026. Die werd georganiseerd door Digitaal Vlaanderen, PIO, VLAIO en Sandbox Vlaanderen. In drie dagen bouwde een gezamenlijk team van Het Facilitair Bedrijf, Arinti, Cronos Public Services en Leap Forward de Regelspotter. Op 22 oktober koos het publiek op de Trefdag Vlaanderen Digitaal de oplossing als winnaar, voor de finalisten van VLAIO en het Agentschap voor Natuur en Bos.
Zien, doen, bewijzen
De Regelspotter ondersteunt gebouwbeheerders in drie stappen. Het zijn dezelfde drie die ook een gasketel thuis in orde houden.
Zien
De gebouwbeheerder ziet welke verplichtingen gelden voor elk van zijn gebouwen, zonder zelf wetteksten te moeten doorploeteren.
Doen
Elke verplichting wordt een concrete taak in de bestaande onderhoudsplanning. Denk aan het onderhoud van een stookketel om de twee jaar, met een seintje wanneer het zover is.
Bewijzen
Zodra de technicus langs geweest is, wordt het attest aan de taak gekoppeld en komt het in het gebouwdossier. Het ligt klaar wanneer een inspecteur of verzekeraar erom vraagt.
Eén register tussen de bronnen en de bestaande systemen
In het midden zit de Regelspotter-motor: complexe tekst gaat erin, concrete acties komen eruit. De motor leest wetgeving in uit de Codex Vlaanderen, het Belgisch Staatsblad en EUR-Lex. Hij kan ook andere documenten verwerken, zoals contracten en vergunningen. Het resultaat is een verplichtingenregister.
Dat register is via een REST-API en MCP gekoppeld aan de systemen die gebouwbeheerders al gebruiken. Het asset- en vastgoedbeheer bevat de gebouwen en installaties. De onderhouds- en ticketingtool beheert taken en attesten. Dashboards tonen de status per gebouw. Niemand hoeft een nieuwe applicatie te leren om zijn verplichtingen op te volgen.
De interface is gebouwd met de componenten van het designsysteem van Digitaal Vlaanderen. Toegankelijkheid zit ingebouwd volgens de WCAG-richtlijnen. Wie andere toepassingen van de Vlaamse overheid kent, vindt meteen zijn weg.
Van wettekst tot verplichting in het register
De motor werkt in drie fasen. Daartussen zitten vaste controlemomenten waarop een mens beslist voordat het proces verdergaat.
1. Voorbereiden
De wettekst wordt uit de pdf gehaald en opgeknipt in afzonderlijke bepalingen. Daarna gaat het systeem na om welke akte het gaat en of die nog in werking is. Een triagestap daarna bepaalt per bepaling of ze een gebouwbeheerder iets kan opleggen. Bij het eerste controlemoment bevestigt of corrigeert een juridisch expert die selectie, nog voor de analyse start.
2. Analyseren
Een orchestrator verdeelt het werk over gespecialiseerde agents. Die schrijven kandidaat-verplichtingen uit en vergelijken ze met wat al in het register staat. Daarna volgt een kwaliteitscontrole in code. Citaten moeten letterlijk overeenkomen met de wettekst, de dekking moet volledig zijn en er mogen geen dubbels in zitten. Faalt die controle, dan gaat de analyse één keer terug met de gevonden problemen als feedback. Bij het tweede controlemoment keurt een juridisch expert elke kandidaat afzonderlijk goed, past ze aan of wijst ze af. Vraagt de expert een herziening, dan worden alleen die kandidaten opnieuw bekeken. Goedgekeurde verplichtingen blijven vergrendeld.
3. Registreren
Deze fase draait volledig in code. Per variant en per type installatie wordt een aparte verplichting opgesteld. Die gaat via de REST-API naar het register. De wetgeving, het brondocument en de onderliggende regels gaan mee. Stelt het systeem een nieuw type installatie voor, dan beslist eerst iemand van data governance bij een derde controlemoment. Alles komt als concept in het register. Publiceren blijft een beslissing van de expert. Na elke stap wordt een checkpoint bewaard, zodat het proces kan herstarten zonder dubbel werk.
AI stelt voor. De mens beslist.
Waar de mens in de lus zit
Tijdens de finale stelde de jury precies die vraag. Het antwoord zit in het ontwerp. Twijfelt de AI over relevantie, analyse of impact, dan beslist een expert. Geen enkele verplichting komt in het register zonder goedkeuring van een expert. Aan de kant van de uitvoering vinkt de gebouwbeheerder een taak pas af wanneer hij bevestigt dat het attest conform is. Is het niet conform, dan beslist een expert of het om een uitzondering gaat of dat het ticket opnieuw opengaat.
Enkele spelregels houden dat samen:
- De zekerheid van de AI bepaalt wanneer een mens moet kijken.
- Elke beslissing krijgt een reden, ook "niet relevant".
- Een audit trail toont wie besliste: een mens, de AI of het systeem.
- Die uitleg wordt gebruikt om de volgende voorstellen beter te maken.
Eén model per rol, code voor de rest
Alle modellen draaien in Azure AI Foundry. Elk model heeft er een afgebakende taak. Mistral Document AI haalt de tekst uit de pdf. Een redeneermodel stuurt de analyse aan en schrijft kandidaat-verplichtingen uit. Een lichter model doet de triage en de vergelijking met het register. Een beslismodel van Microsoft geeft de reviewer per kandidaat een gekalibreerde zekerheidsscore, zonder zelf tekst te genereren. Alles wat voorspelbaar is, gebeurt in gewone code. Denk aan het knippen van tekst, de kwaliteitscontrole en de registratie. Ook het koppelen, de taken en de audit trail lopen via code.
Die verdeling houdt de kosten laag. De volledige analyse van een wettekst van 30 pagina's kost ongeveer 2 euro aan AI. Dat gaat van de relevantiecheck tot de juridische analyse. Vier keuzes maken dat mogelijk:
- AI leest één keer. Daarna draait alles op vaste logica. Of een regel nu voor 60 of voor 600 gebouwen geldt, de AI-kost blijft dezelfde.
- Goedkope modellen voor eenvoudige taken. Dure modellen komen alleen aan bod voor moeilijk redeneerwerk en om de eenvoudigere modellen aan te sturen.
- Zuinig met tokens. Gestructureerde antwoorden en herbruikbare instructies.
- Beslismodel en batching. Classificeren gebeurt zonder LLM. Verzoeken worden gebundeld.
De Regelspotter in cijfers
Wat het kan opleveren
Het team schat dat de Regelspotter de administratieve last rond het opvolgen van regelgeving kan halveren. Bij Het Facilitair Bedrijf komt dat neer op zo'n 600.000 euro minder loonkost per jaar. Dat cijfer is een raming op basis van de huidige werkwijze en nog geen gemeten resultaat.
Het grootste potentieel zit in de schaal. Het Facilitair Bedrijf beheert ongeveer 300 gebouwen. De Vlaamse overheid, steden, gemeenten en andere lokale besturen beheren samen meer dan 30.000 gebouwen die onder dezelfde regelgeving vallen. Omdat de oplossing modulair is opgebouwd, liggen ook andere toepassingen binnen bereik. Je weet welke verplichtingen je overneemt bij de aankoop van een gebouw, je maakt de juiste keuzes tijdens een bouwproject en je ziet de kosten van verplichte ingrepen aankomen.
Van prototype naar productie
Na drie dagen hacken draait de register-API al in Azure. De analysepijplijn draait voorlopig lokaal. De stappen om die naar Azure te brengen zijn in kaart gebracht. Een hackathon levert een werkend prototype op. De echte waarde ontstaat pas wanneer gebouwbeheerders er elke dag mee werken. Daar willen we samen met Het Facilitair Bedrijf naartoe.
Proficiat aan het hele team! Bedankt aan Digitaal Vlaanderen, PIO, VLAIO en Sandbox Vlaanderen voor de organisatie. Moet jouw organisatie ook regelgeving, contracten of andere complexe documenten omzetten in concrete acties? Laat er ons samen naar kijken!
