DeepGov, waarom honderden gemeenten niet elk hun eigen AI hoeven te bouwen

Stel je voor: een gemeente van veertigduizend inwoners start een AI-pilot. Een chatbot die vragen over paspoorten en vergunningen beantwoordt, een zoekfunctie over beleidsdocumenten, transcriptie van raadsvergaderingen. Er wordt een leverancier ingehuurd, er komt een projectteam, er wordt een half jaar gebouwd en getest. Het resultaat is best aardig.

En dan het ongemakkelijke deel: drie gemeenten verderop gebeurt precies hetzelfde. Zelfde soort chatbot, zelfde soort documentzoeker, vaak zelfs dezelfde leverancier. Andere offerte, ander projectteam, zelfde fouten. Vermenigvuldig dat met de ruim driehonderd gemeenten die Nederland telt, plus provincies, waterschappen en uitvoeringsorganisaties, en je ziet een patroon dat met belastinggeld wordt betaald: iedereen vindt hetzelfde wiel uit, en niemand mag in andermans wiel kijken.

Ik wil hier een denkrichting neerleggen. Werktitel: DeepGov. Een open-source AI-platform voor overheden, gebouwd als gedeelde bouwblokken in plaats van losse pilots. Het bestaat niet. Dit is geen product, geen aankondiging en geen verkapte offerte. Het is een voorstel om hardop over na te denken, omdat ik denk dat de techniek er klaar voor is en de organisatievorm nog niet.

Wat er nu gebeurt: honderd keer dezelfde pilot

Onder bijna elke gemeentelijke AI-pilot zit dezelfde technische stapel. Een taalmodel, ergens gehost. Een laag die documenten ophaalt en doorzoekbaar maakt, meestal met embeddings en een vector database: het patroon dat RAG heet. Een chatinterface erbovenop. Een stukje logging, als je geluk hebt. En een rechtenmodel, als je heel veel geluk hebt.

Die stapel is niet uniek per gemeente. De vergunningprocedure in Assen verschilt inhoudelijk van die in Middelburg, maar de techniek om er vragen over te beantwoorden is identiek. Toch wordt die techniek telkens opnieuw gekocht, opnieuw geconfigureerd en opnieuw verkeerd ingericht. De fouten zijn ook telkens hetzelfde: documenten zonder rechtenstructuur in een vectordatabase gepompt, geen logging van wat het model met persoonsgegevens doet, geen plan voor wat er gebeurt als de leverancier stopt of wordt overgenomen.

Het zuurste is dat de lessen niet reizen. Als gemeente A ontdekt dat hun chatbot verouderde informatie over kwijtschelding geeft omdat de bron-PDF's nooit worden ververst, dan leert gemeente B dat niet. Die ontdekt het zelf, een jaar later, in productie.

Het idee: gedeelde bouwblokken in plaats van losse projecten

Draai het om. Stel dat overheden de generieke laag samen zouden bouwen en beheren, als open source. Niet één grote alles-in-een applicatie, maar een set bouwblokken die elke overheidsorganisatie kan combineren:

een chatcomponent die aan elke OpenAI-compatible API te hangen is, dus ook aan modellen die in Europa of in het eigen datacenter draaien
een documentzoeklaag: ingestie, chunking, embeddings, vector search, met versiebeheer zodat verouderde stukken niet blijven rondspoken
transcriptie voor raadsvergaderingen en hoorzittingen, lokaal draaiend zodat de audio het gebouw niet hoeft te verlaten
een rechtenmodel dat aansluit op wat er al is, zodat een medewerker via AI nooit meer kan zien dan zonder AI
logging en audit trails als standaardonderdeel, niet als optie achteraf

De inhoud blijft lokaal: elke gemeente koppelt haar eigen documenten, processen en huisstijl. De motor eronder is gedeeld. Hosting kan lokaal, bij een gemeenschappelijke voorziening of bij een Europese partij, zolang de organisatie zelf bepaalt waar data en modellen draaien.

Het belangrijkste woord in dit hele verhaal is controleerbaar. Open source betekent hier niet gratis, en ook niet hobbyisme. Het betekent dat de code die beslissingen over burgers voorbereidt door iedereen te inspecteren is: door de gemeenteraad die er vragen over stelt, door de journalist die een Woo-verzoek indient, door de security-onderzoeker die een lek zoekt, en door de buurgemeente die hetzelfde wil draaien.

Waarom open source juist voor overheden logisch is

Voor een commercieel bedrijf is open source een afweging. Voor een overheid is het eigenlijk de natuurlijke staat, om drie redenen.

Ten eerste de transparantieplicht. Een overheid moet kunnen uitleggen hoe ze tot beslissingen komt. Dat raakt aan wetgeving als de Woo en aan de discussie over het algoritmeregister. Als een AI-systeem antwoorden voorbereidt voor burgers, is "dat zit in het product van de leverancier" geen acceptabel antwoord. Bij open source is de tegenvraag tenminste te beantwoorden: hier is de code, hier is de prompt, hier zijn de logs.

Ten tweede het geld. Software die met belastinggeld wordt ontwikkeld en daarna achter het slot van één leverancier verdwijnt, is twee keer betalen. Eén keer voor de bouw, en daarna elk jaar opnieuw omdat overstappen praktisch onmogelijk is gemaakt. Vendor lock-in is voor een bedrijf vervelend. Voor een overheid is het een structureel weglekken van publiek geld naar een onderhandelingspositie die ze zelf heeft weggegeven. De Nederlandse rijksoverheid heeft niet voor niets als uitgangspunt geformuleerd dat overheidssoftware in principe als open source vrijgegeven zou moeten worden, het zogenoemde "open, tenzij".

Ten derde de audits. De AI Act gaat eisen stellen aan systemen die overheden inzetten, zeker waar besluiten over mensen in het spel zijn. Honderd gesloten systemen bij honderd gemeenten betekent honderd aparte audits, elk tegen een leverancier die zijn binnenwerk liever niet laat zien. Eén gedeelde open codebase kan één keer grondig worden doorgelicht, en elke gemeente die hem draait profiteert van die toets. Dat maakt een systeem nog niet automatisch compliant, dat hangt ook af van data, inrichting en gebruik. Maar het scheelt enorm in de controleerbaarheid van de basis.

Wat er in de weg zit

Als dit zo logisch is, waarom bestaat het dan niet? Drie eerlijke antwoorden.

De aanbestedingscultuur. Gemeentelijke inkoop is ingericht op het kopen van producten en diensten, niet op het bijdragen aan een gedeelde codebase. Een aanbesteding wil een leverancier, een prijs, een contract en iemand om aan te kijken als het misgaat. "Wij leggen drie ontwikkelaars en hostingbudget in op een gezamenlijk platform" past niet in dat format. Het kan wel, er zijn constructies voor, maar het vergt inkopers en juristen die buiten het standaardtraject durven te denken. Die zijn schaars en hebben het druk.

Beheer en eigenaarschap. Open source is geen abonnement waar onderhoud automatisch bij zit. Iemand moet security-patches draaien, dependencies bijwerken, releases testen en de roadmap bewaken. De grootste misvatting over open source bij overheden is dat het gratis is. Het is niet gratis, het is anders gefinancierd: je betaalt voor mensen en beheer in plaats van voor licenties en lock-in. Zonder een duidelijke beheerorganisatie, met budget en mandaat, wordt elk gezamenlijk platform na de eerste bestuurswissel een weeskind.

De governance-vraag. Wie beslist wat erin komt? Als tweehonderd gemeenten meedoen en er ontstaat discussie over de standaard-prompt van de chatbot, wie hakt de knoop door? Dit klinkt als een detail, maar het is precies waar gezamenlijke ICT-initiatieven historisch op stuklopen: niet op de techniek, maar op de vraag wie de pen vasthoudt.

Het begint niet bij nul

Het goede nieuws: de beweging bestaat al, alleen nog niet voor AI. In Nederland werken gemeenten binnen Common Ground aan een modernere, modulaire informatievoorziening met gedeelde componenten en open standaarden, een initiatief dat vanuit de gemeentelijke wereld zelf is ontstaan. De precieze status en het tempo verschillen per onderdeel, en ik wil het niet mooier maken dan het is. Maar het principe dat gemeenten samen herbruikbare software ontwikkelen in plaats van driehonderd keer hetzelfde te kopen, is daar al geland.

Ook breder is er beweging. Verschillende Europese overheden experimenteren met open-source werkomgevingen en eigen hosting om minder afhankelijk te worden van Amerikaanse cloudleveranciers. De richting is helder, ook al verschilt de uitvoering per land. Een gedeelde AI-laag zou daar logisch op aansluiten: de modellen kunnen open source zijn, de hosting kan Europees of lokaal, en de bouwblokken eromheen zijn precies het soort generieke software waar samenwerking het meeste oplevert.

Technisch is dit het minst spannende deel van het verhaal. Open modellen zijn goed genoeg voor documentzoeken, samenvatten en transcriptie. RAG-pijplijnen zijn een bekend patroon. Wat ontbreekt is geen techniek, maar een plek waar dit samenkomt met eigenaarschap en beheer.

Wat een gemeente morgen al anders kan doen

Je hoeft niet te wachten op een platform dat nog niet bestaat. Een paar dingen kunnen nu al.

Eis bij elke AI-aanbesteding een exit-scenario: waar staan de data, de embeddings en de prompts, en in welk formaat krijg je ze mee als het contract stopt? Vraag of de oplossing op een OpenAI-compatible API werkt, zodat het model vervangbaar is zonder de hele applicatie weg te gooien. Vraag of de leverancier bereid is de generieke delen open source te maken, en zo nee, waarom niet. En bel die buurgemeente met dezelfde pilot. Niet voor een convenant of een stuurgroep, gewoon om fouten en evaluaties uit te wisselen. Dat is de goedkoopste vorm van samenwerking die er bestaat, en hij wordt het minst gebruikt.

Voor wie verder wil: dit soort initiatieven beginnen zelden bij alle gemeenten tegelijk. Ze beginnen bij vijf of tien organisaties die samen één bouwblok adopteren, bijvoorbeeld lokale transcriptie van raadsvergaderingen, en die hun configuratie en lessen publiek delen. Klein, concreet, controleerbaar. Vandaaruit groeit het, of het sterft in stilte, en ook dat is dan goedkoop geleerd.

De vraag die overblijft

DeepGov is op dit moment niet meer dan een naam en een schets. Misschien komt het er nooit in deze vorm, en wordt het iets dat uit Common Ground groeit, of uit een Europese samenwerking, of uit een paar eigenwijze gemeenten die elkaar vinden. De vorm maakt mij eerlijk gezegd weinig uit.

Waar het om gaat is de onderliggende keuze. Overheden gaan de komende jaren hoe dan ook AI inzetten, dat is geen open vraag meer. De open vraag is of ze dat driehonderd keer apart doen, in gesloten systemen die niemand mag inzien, of één keer samen, in code die van iedereen is en die iedereen mag controleren. Het eerste is de weg van de minste weerstand. Het tweede is wat je van een overheid mag verwachten.

↘︎ ALLE ARTIKELEN

Waarom Europa eigen AI-modellen moet ontwikkelen 13 juni 2026. Anthropic moest Fable 5 en Mythos 5 op overheidsbevel wereldwijd uitzetten. Wat dat zegt over waarom Europa zelf modellen moet kunnen maken.
De verborgen dataflow achter een simpele AI-vraag 10 juni 2026. Wat er technisch gebeurt tussen je vraag aan een AI-chat en het antwoord, en waar je data overal terechtkomt.
RAG begrijpelijk uitgelegd 10 juni 2026. RAG in gewone taal: chunking, embeddings, vector databases, retrieval en de valkuilen in productie.
Het verschil tussen data residency en echte data-soevereiniteit 10 juni 2026. Data in een Europees datacenter is nog geen soevereine data. Over software, recht en encryptiesleutels.
Shadow AI: het datalek dat al gebeurd is 10 juni 2026. Medewerkers gebruiken allang AI-tools, met of zonder beleid. Wat er met die data gebeurt en wat wel werkt.
Van AI-demo naar productie 10 juni 2026. Waarom AI-pilots stranden en wat de stap van prototype naar live systeem echt vraagt.
Embeddings en vector databases: de kopie van je bedrijfskennis waar niemand het over heeft 10 juni 2026. Wat een embedding technisch is, hoe similarity search werkt en waarom je embeddings moet behandelen als een kopie van je bedrijfskennis.
AI-geletterdheid: waarom tooling zonder begrip een risico is 10 juni 2026. Licenties uitdelen is geen AI-strategie. Wat AI-geletterdheid concreet inhoudt, hoe het raakt aan de AI Act en hoe je het aanpakt zonder saaie e-learning.
Hoe je een open-source model host 10 juni 2026. Wat je nodig hebt om een open model zoals Llama of Mistral zelf te draaien: gewichten, VRAM, een inference server, kwantisatie en alles eromheen.
Agents, tool permissions en prompt injection: als AI niet alleen praat maar ook doet 10 juni 2026. Een AI-agent kan mailen, bestanden wijzigen en systemen aanroepen. Waarom tool permissions en prompt injection dan het echte veiligheidsvraagstuk zijn.
Waarom data in Europa houden belangrijk kan zijn 10 juni 2026. Vijf praktische redenen om data in Europa te houden, van AVG en aanbestedingen tot continuïteit. En wanneer het eerlijk gezegd weinig uitmaakt.
Model gateways en LLM-routers, de verkeerstoren van je AI-landschap 10 juni 2026. Waarom je applicaties niet rechtstreeks met modelproviders wilt laten praten. Wat een model gateway en een LLM router doen, en waar het risico zit.
De AI Act is geen beleidsstuk, het is een technisch project 10 juni 2026. De AI Act vraagt om inventarisatie, logging en toegangsbeheer. Waarom een beleidsdocument alleen niet genoeg is en wat je technisch moet kunnen leveren.
Bedrijfskennis veilig aan AI koppelen: wie wat mag zien geldt ook voor de assistent 10 juni 2026. Rechten, document permissions, verwijderde documenten en logging bepalen of een AI-assistent op bedrijfskennis veilig is. Zo pak je de governancekant aan.
GPU-infra zonder mist: VRAM, batching, latency en wat AI echt kost 10 juni 2026. Waarom AI op GPU's draait, wat VRAM bepaalt, waarom een wachtende GPU geld verbrandt en hoe je nuchter rekent aan huren, kopen en spot instances.
Observability, logs en audit trails voor AI, kun je terugzien wat er gebeurde? 10 juni 2026. Als niemand kan terugzien wat de AI deed, heb je een probleem. Wat je logt, hoe je privacy bewaakt en hoe je van logs naar echte evaluatie komt.
OpenAI-compatible APIs, de stekker die overal in past 10 juni 2026. Hoe het API formaat van OpenAI de standaard werd voor bijna elk AI model, waarom dat wisselen makkelijk maakt en waar de compatibiliteit ophoudt.
Self-hosting, Europese cloud en vendor lock-in, waar zit je nou echt vast? 10 juni 2026. Lock-in bij AI zit niet in het model maar in prompts, embeddings, logs en processen. Een gelaagd denkmodel voor self-hosting en Europese cloud.
Use-case: host je eigen model in Europa 10 juni 2026. Hoe een zorginstelling stap voor stap een open model in Europa ging hosten. Van modelkeuze en GPU tot de eerste echte productieproblemen.
One man company, hoe ik in mijn eentje bouw wat eerder een team vroeg 10 juni 2026. Hoe een persoon met AI tooling een productportfolio kan bouwen en draaien. Wat AI overneemt, wat niet, en waar het schuurt als alles jouw probleem is.
Reverse engineering, bouw een compleet softwarepakket na in een dag 10 juni 2026. Met AI tooling bouw je de functionaliteit van bestaande software in een dag na. Wat dat zegt over waar softwarewaarde nu echt zit, en waar niet.
Use-case: je complete boekhouding laten doen door een agent 10 juni 2026. Een AI agent die bonnetjes uit je mail vist en aan transacties koppelt. Wat er technisch voor nodig is, waar het eng wordt en welke vangrails je wilt.
Een supervisor-agent voor al mijn projecten, een kopie van mezelf 10 juni 2026. Hoe een supervisor-agent al je projecten kan bewaken, kleine fixes zelf doet en wekelijks rapporteert. Wat al werkt, wat wensdenken is.
DeepGov, waarom honderden gemeenten niet elk hun eigen AI hoeven te bouwen 10 juni 2026. Een voorstel voor een open source AI platform voor overheden. Gedeelde bouwblokken, Europese hosting en controleerbare code in plaats van losse pilots.
The age of open source: de standaardkeuze voor AI kantelt 10 juni 2026. Open modellen en open AI tooling zijn volwassen. Wat je nog koopt verschuift naar gemak en garanties, en waarom dat voor Europa interessant is.
Je moet het kunnen bedenken, AI werkt vooral als je het grotere plaatje ziet 10 juni 2026. De bottleneck bij AI zit niet meer in de techniek maar in het bedenken. Waarom de beste toepassingen komen van mensen die het hele proces overzien.
Gebruiken we over twee jaar nog wel een scherm? 10 juni 2026. Agents kunnen taken steeds vaker zelf afronden. Wat betekent dat voor het scherm, en moet je nog interfaces bouwen of vooral taken en API's?