i-Police kostte België 139 miljoen euro. Wat als we het vandaag opnieuw zouden bouwen met AI en open-source software?

De mislukking van i-Police roept een interessante vraag op: hoeveel zou een vergelijkbaar politieplatform vandaag kosten als we het volledig opnieuw ontwikkelen met Python, Django, open-source technologie en AI-programmeerassistenten? En zou een relatief klein, gespecialiseerd ontwikkelteam met permanente kwaliteitscontrole betere resultaten kunnen bereiken?

Op 28 oktober 2026 publiceerde het Rekenhof zijn audit over het beheer van het i-Police-programma. De cijfers zijn opmerkelijk. Voor de modernisering van de Belgische politiesystemen was uiteindelijk een budget van 299,7 miljoen euro voorzien. Daarvan werd 139,4 miljoen euro daadwerkelijk uitgegeven.

Het resultaat? Eind 2024 was het programma volgens een evaluatie voor 41,7% gerealiseerd, maar geen enkel subproject was volledig afgerond. In december 2025 werd het hoofdcontract stopgezet.

Het is belangrijk om die cijfers correct te interpreteren. Niet alle uitgaven zijn verloren gegaan. Zo werd ook geïnvesteerd in Focus@GPI, een platform dat daadwerkelijk door de politie wordt gebruikt. Toch blijft de vraag waarom een dergelijk groot IT-programma niet tot de beoogde geïntegreerde oplossing heeft geleid.

Ik ontwikkel zelf al jarenlang software, voornamelijk met Python, Django, PostgreSQL en andere open-source technologieën. De afgelopen jaren is mijn manier van werken bovendien aanzienlijk veranderd door het gebruik van large language models (LLM's), waaronder OpenAI Codex en Claude.

Daarom wilde ik eens een andere oefening maken.

Niet onderzoeken wie juridisch verantwoordelijk is voor het mislukken van i-Police. Daarover loopt een gerechtelijke procedure. Maar wel bekijken hoe we vandaag een vergelijkbaar systeem zouden kunnen bouwen, met een andere technische architectuur, een kleinere organisatie en AI als hulpmiddel tijdens het volledige ontwikkelingsproces.

Wat moest i-Police eigenlijk kunnen?

Het oorspronkelijke doel was veel ambitieuzer dan het ontwikkelen van een nieuwe politieapplicatie.

De Belgische politie gebruikt verschillende informatiesystemen die historisch onafhankelijk van elkaar zijn ontwikkeld. i-Police moest die systemen samenbrengen in een geïntegreerd platform.

Het programma omvatte onder andere:

• Een centraal Records Management System (RMS) voor de registratie van politiegegevens.

• Een Case Management System (CMS) voor onderzoeken en gerechtelijke dossiers.

• Gegevensuitwisseling met onder andere Interpol, Europol en Schengen.

• Geavanceerde zoekfunctionaliteiten en analyse van relaties tussen personen, voertuigen, locaties en gebeurtenissen.

• Verwerking van documenten, afbeeldingen, audio en videomateriaal.

• Geolokalisatie en analyse van publiek beschikbare informatie (OSINT).

• AI-ondersteunde gegevensanalyse.

• Beveiligde mobiele toepassingen voor politieagenten op het terrein.

Daarnaast moest het systeem rekening houden met meertaligheid, complexe toegangsrechten, wettelijke verplichtingen en de migratie van historische gegevens.

Dat is geen gewone bedrijfsapplicatie. Het is een omvangrijk, bedrijfskritisch informatieplatform dat permanent beschikbaar en bijzonder goed beveiligd moet zijn.

De oorspronkelijke keuze: commerciële software integreren

Bij de voorbereiding van i-Police werd gekozen om zoveel mogelijk bestaande commerciële software te gebruiken.

Die beslissing was op zichzelf begrijpelijk. Software die al bij andere politieorganisaties wordt gebruikt, heeft normaal gesproken bepaalde voordelen. De functionaliteiten bestaan al, problemen zijn eerder ontdekt en de leverancier verzorgt het onderhoud.

De uiteindelijke oplossing zou steunen op ongeveer twintig standaardsoftwareproducten, met NicheRMS voor dossierbeheer en TA9 IntSight voor gegevensanalyse als belangrijke onderdelen.

Maar daar zit ook een probleem.

Wanneer twintig verschillende producten moeten samenwerken, ontstaat een complexe verzameling van afhankelijkheden. Elk product heeft zijn eigen architectuur, versies, licenties, technische beperkingen en ontwikkelplanning.

Het Rekenhof beschrijft hoe de integratie van deze producten veel moeilijker bleek dan verwacht.

Bovendien werd voor ongeveer 30,7 miljoen euro aan licenties betaald. Volgens de federale politie hadden licenties ter waarde van 21,6 miljoen euro uiteindelijk geen nut meer voor de organisatie.

Dat bracht mij bij een interessante gedachte: waarom zouden we niet zoveel mogelijk zelf ontwikkelen, boven op een beperkt aantal bewezen open-source componenten?

Een alternatieve architectuur met Django en Python

Als ik vandaag vanaf nul aan een dergelijk project zou beginnen, zou ik de technische architectuur bewust eenvoudig proberen te houden.

Niet door alle functionaliteiten in één gigantische applicatie onder te brengen, maar door een modulaire architectuur te bouwen met een gemeenschappelijke technologische basis.

Python en Django zouden de kern vormen voor de businesslogica, gebruikersbeheer, toegangsrechten, API's, dossierbeheer en administratieve processen.

Voor andere onderdelen zou ik gespecialiseerde technologieën gebruiken.

Onderdeel	Mogelijke technologie
Backend en API's	Python, Django, Django REST Framework
Relationele databanken	PostgreSQL, PostGIS
Zoeken en indexeren	OpenSearch
Achtergrondtaken	Celery, Redis of RabbitMQ
Documenten en bestanden	S3-compatibele objectopslag
Frontend	HTMX, Alpine.js, Tailwind CSS; waar nodig een gespecialiseerde frontend
Mobiele applicaties	Flutter
Videoverwerking en streaming	FFmpeg, GStreamer en geschikte streamingservers
Containerisatie	Docker, Kubernetes waar nodig
Monitoring	Prometheus, Grafana
AI-infrastructuur	Lokale open-weight modellen, vLLM, LiteLLM

Django hoeft natuurlijk niet alles zelf te doen. Voor realtime video, zware gegevensverwerking of specifieke netwerkprotocollen zijn andere technologieën geschikter.

Het voordeel zit vooral in standaardisatie.

Wanneer ontwikkelaars dezelfde programmeertaal, dezelfde conventies, dezelfde beveiligingsprincipes en dezelfde ontwikkelomgeving gebruiken, wordt het eenvoudiger om code te begrijpen, te testen en te onderhouden.

Bovendien zijn de meeste genoemde technologieën open source.

Dat betekent niet dat ze gratis te exploiteren zijn. Servers, onderhoud, beveiliging en gespecialiseerde ontwikkelaars blijven geld kosten. Maar de afhankelijkheid van commerciële licentiemodellen kan aanzienlijk worden verminderd.

Wat verandert AI aan softwareontwikkeling?

Dit is volgens mij het interessantste onderdeel van de oefening.

De ontwikkeling van software in 2026 is niet meer dezelfde als vijf jaar geleden.

Ik gebruik zelf regelmatig LLM's om bestaande code te analyseren, nieuwe functionaliteiten te ontwikkelen, fouten op te sporen, databasestructuren te verbeteren en technische documentatie op te stellen.

Met tools zoals Codex en Claude kunnen ontwikkelaars een groot deel van het repetitieve programmeerwerk versnellen.

Dat betekent niet dat AI zelfstandig een veilig politieplatform kan bouwen.

Een LLM begrijpt niet automatisch alle operationele behoeften van een politieorganisatie. Het kan bovendien fouten introduceren, verkeerde aannames maken of beveiligingsproblemen over het hoofd zien.

Maar een ervaren ontwikkelaar die deze tools goed gebruikt, kan bepaalde werkzaamheden aanzienlijk sneller uitvoeren.

De interessante vraag is dus niet hoeveel programmeurs we volledig kunnen vervangen door AI, maar hoeveel productiever een goed georganiseerd ontwikkelteam kan worden.

En hoe we de vrijgekomen capaciteit kunnen inzetten voor betere kwaliteitscontrole.

Twee teams: één ontwikkelt, het andere probeert alles kapot te maken

Ik zou een dergelijk project organiseren rond twee grotendeels onafhankelijke groepen.

De eerste groep ontwikkelt de software. Ze gebruikt AI intensief voor het schrijven en analyseren van code, het bouwen van integraties en het automatiseren van repetitieve werkzaamheden.

De tweede groep heeft een andere opdracht: voortdurend zoeken naar problemen.

Niet alleen controleren of een knop werkt, maar ook proberen het systeem onderuit te halen.

Wat gebeurt er wanneer duizenden gebruikers tegelijkertijd gegevens opvragen? Kan iemand informatie bekijken waarvoor hij geen toestemming heeft? Wat gebeurt er wanneer een externe databank tijdelijk niet beschikbaar is? Kunnen documenten worden gemanipuleerd? Zijn er fouten in de API's? Kunnen gegevens verloren gaan tijdens een migratie?

Ook deze tweede groep kan AI gebruiken om testscenario's te genereren, code te analyseren en onverwachte combinaties van invoer te onderzoeken.

De teams werken met dezelfde functionele eisen, maar controleren elkaars aannames en resultaten.

Daarbij zou ik een onafhankelijke security-audit behouden. Een systeem dat door twee interne teams is getest, is immers niet automatisch veilig.

Het doel is niet om te beweren dat software 100% foutloos kan worden. Dat is niet realistisch.

Het doel is om zo dicht mogelijk bij een aantoonbaar hoog niveau van betrouwbaarheid en beveiliging te komen, met meetbare kwaliteitscriteria, permanente monitoring en gecontroleerde releases.

Hoeveel mensen zouden we nodig hebben?

Laten we een eerste hypothetische berekening maken.

Ik ga uit van een gespecialiseerd team van 38 mensen, verdeeld over ontwikkeling, kwaliteitscontrole, infrastructuur, beveiliging, analyse en projectmanagement.

Functie	Aantal
Programma- en projectmanagers	2
Software- en securityarchitecten	2
Python/Django-ontwikkelaars	8
Frontend- en mobiele ontwikkelaars	4
Data- en integratiespecialisten	5
AI/ML-engineers	3
DevOps- en infrastructuurspecialisten	3
QA- en testautomatiseringsspecialisten	5
Securityspecialisten en pentesters	3
Businessanalisten	3
Totaal	38

Dit zou geen traditioneel team zijn waarbij iedere ontwikkelaar uitsluitend zijn eigen stukje code schrijft.

Iedere ontwikkelaar werkt met AI-assistenten. Tests worden zoveel mogelijk automatisch gegenereerd en uitgevoerd. Documentatie wordt tijdens de ontwikkeling bijgewerkt. Codewijzigingen worden continu gecontroleerd.

Ik zou minstens twee projectmanagers voorzien: één voor de ontwikkeling en één voor kwaliteit, beveiliging en de coördinatie van de onafhankelijke controles.

Voor een nationaal politieprogramma blijft daarnaast actieve betrokkenheid van politiemedewerkers, juridische deskundigen en gegevensbeheerders noodzakelijk. Die capaciteit zit niet volledig in bovenstaande tabel.

Wat zou zo'n ontwikkeling kosten?

Voor deze eerste denkoefening gebruik ik geschatte commerciële tarieven voor gespecialiseerde IT-profielen.

De maandelijkse kostprijs per persoon zou, afhankelijk van het profiel, ongeveer tussen 8.000 en 16.000 euro liggen. Dat zijn geen nettolonen, maar geraamde kosten voor het inzetten van deze specialisten.

Voor een team van 38 personen komen we ruwweg uit op 390.000 tot 490.000 euro per maand.

Bij een ontwikkelingsperiode van drie jaar geeft dat:

Personeelskosten: ongeveer 14 tot 18 miljoen euro.

Daarboven komen de kosten van infrastructuur, hardware, lokale AI-modellen, beveiligingsaudits, gegevensmigratie, opleidingen, ondersteuning en een financiële reserve.

Een eerste werkhypothese zou daarom een budget van ongeveer 25 tot 40 miljoen euro over drie jaar kunnen zijn.

Dat klinkt natuurlijk bijzonder aantrekkelijk tegenover het oorspronkelijke i-Police-budget van 299,7 miljoen euro.

Maar we moeten voorzichtig zijn met die vergelijking.

Met 25 tot 40 miljoen euro kan een ervaren team mogelijk een aanzienlijk deel van een modern politieplatform ontwikkelen. Het is echter niet aangetoond dat daarmee ook alle oorspronkelijke i-Police-functionaliteiten, alle migraties, alle internationale koppelingen en de volledige nationale uitrol gerealiseerd kunnen worden.

Voor een werkelijk gelijkwaardige vergelijking zouden we iedere functionele eis afzonderlijk moeten begroten.

Een volledig nationaal programma kan daardoor aanzienlijk duurder uitvallen dan deze eerste hypothese.

Toch is het verschil groot genoeg om de alternatieve aanpak serieus te onderzoeken.

En wat als alle AI lokaal draait?

Een politieorganisatie kan niet zomaar vertrouwelijke informatie naar externe AI-diensten versturen.

Daarom zou ik ook een volledig lokale AI-infrastructuur onderzoeken.

Vandaag bestaan er open-weight taalmodellen die op eigen servers kunnen worden uitgevoerd. Met software zoals vLLM en LiteLLM kunnen verschillende modellen via een gemeenschappelijke interface worden aangeboden.

Dat biedt een interessant voordeel: wanneer een beter model beschikbaar komt, kan het bestaande model worden vervangen zonder dat de volledige applicatie opnieuw ontwikkeld moet worden.

De AI-functionaliteiten worden zo minder afhankelijk van één leverancier.

Een dergelijke architectuur kan worden gebruikt voor het doorzoeken van documenten, samenvatten van dossiers, herkennen van relevante informatie en ondersteunen van administratieve werkzaamheden.

Daarbij moeten toegangsrechten ook op AI-niveau worden afgedwongen. Een taalmodel mag nooit informatie kunnen ophalen die de betreffende gebruiker niet mag raadplegen.

Voor gevoelige toepassingen moeten AI-antwoorden bovendien controleerbaar blijven en mogen ze niet zonder menselijke beoordeling worden gebruikt voor ingrijpende beslissingen.

Ook lokaal draaiende AI is niet gratis. GPU-servers, elektriciteit, onderhoud en beveiliging kosten geld. Maar de organisatie behoudt wel veel meer controle over de gegevensverwerking.

Wie is eigenaar van de software?

Dit is een ander belangrijk punt.

Wanneer een overheid honderden miljoenen euro's investeert in softwareontwikkeling, lijkt het mij logisch dat zij zoveel mogelijk eigenaar wordt van de resultaten.

In mijn alternatieve scenario zou de opdrachtgever eigenaar zijn van alle specifiek ontwikkelde broncode, documentatie, tests, configuraties en intellectuele rechten op het maatwerk.

De code zou worden beheerd in repositories onder controle van de opdrachtgever, met reproduceerbare builds en duidelijke procedures voor kennisoverdracht.

De open-source componenten blijven uiteraard onder hun eigen licenties vallen.

Het voordeel is dat een andere ontwikkelpartij het werk later kan overnemen zonder afhankelijk te zijn van één oorspronkelijke leverancier.

Hetzelfde geldt voor de AI-modellen: de applicatie moet niet afhankelijk zijn van één specifieke LLM-aanbieder.

Waarom grote IT-projecten niet alleen een programmeerprobleem zijn

Het Rekenhof beschrijft in zijn audit een reeks organisatorische problemen die minstens zo belangrijk zijn als de technische moeilijkheden.

Er ontbrak een voldoende stabiele overkoepelende architectuur. Projecten waren sterk afhankelijk van elkaar. De planning werd onvoldoende geconsolideerd. De criteria voor de oplevering van functionaliteiten waren niet altijd duidelijk.

Bovendien werd een groot aantal projecten opgestart voordat de eerste proefprojecten succesvol waren afgerond.

Dat is precies wat ik bij een alternatieve ontwikkeling zou willen vermijden.

Eerst een beperkte maar volledig werkende toepassing ontwikkelen. Daarna de architectuur, integraties en beveiliging grondig testen. Pas wanneer de resultaten aantoonbaar voldoen aan de eisen, de volgende modules toevoegen.

Niet tientallen projecten tegelijk opstarten omdat er toevallig budget beschikbaar is.

En vooral: voortdurend kunnen aantonen welke functionaliteiten daadwerkelijk werken.

Een experiment dat de moeite waard is

Ik beweer niet dat we met 38 ontwikkelaars en enkele AI-modellen zomaar het volledige Belgische politieplatform kunnen bouwen voor een fractie van het oorspronkelijke budget.

Daarvoor is het project te complex en zijn er te veel onbekende factoren.

Maar ik ben er wel van overtuigd dat de manier waarop we software ontwikkelen fundamenteel aan het veranderen is.

AI maakt bepaalde ontwikkeltaken sneller. Open-source technologie vermindert de afhankelijkheid van commerciële softwareleveranciers. Automatische tests maken intensievere kwaliteitscontrole mogelijk. En een modulaire architectuur kan helpen om risico's beter te beheersen.

De vraag is hoeveel dat in een groot overheidsproject daadwerkelijk kan opleveren.

Mijn volgende stap zou zijn om de functionele vereisten van i-Police uit het auditrapport te analyseren en voor ieder onderdeel een alternatieve technische oplossing, ontwikkeltijd en kostprijs te ramen.

Niet op basis van marketingbeloftes over AI, maar op basis van concrete modules, ontwikkelaars, werkuren, infrastructuur en testvereisten.

Want misschien is de belangrijkste vraag niet waarom i-Police bijna 300 miljoen euro mocht kosten, maar hoeveel een vergelijkbaar systeem vandaag werkelijk zou moeten kosten als we het vanaf het begin anders organiseren.

Bron: Rekenhof, Audit van het beheer van het i-Police-programma, 28 oktober 2026.

De vermelde alternatieve budgetten en personeelsramingen zijn eigen indicatieve berekeningen en geen conclusies van het Rekenhof.