← Alle inzichten
Leiders

Een AI-roadmap voor de komende 12 maanden

De meeste AI-roadmaps zijn lijsten van wat AI gaat doen. Ze falen omdat ze fundament en features door elkaar halen. Zo structureer je het juist.

Voor wie? CTO’s, IT-managers en directeuren die AI structureel willen invoeren — en die al één of meer pilots achter de rug hebben zonder duidelijk vervolg.

Kort: Een AI-roadmap is geen lijst van systemen die je wilt bouwen. Het is een volgorde van capaciteiten die je wilt opbouwen. Wie dat onderscheid overslaat, bouwt wel systemen — maar geen organisatie die er verantwoord mee kan omgaan. De workshop voor leaders werkt dit model uit voor je specifieke situatie.


Veel organisaties beginnen hun AI-roadmap op de verkeerde plek: bij de meest zichtbare use case, niet de meest impactvolle. Een klantgerichte chatbot haalt de demo goed door, maar het is ook het systeem met de meeste risico-exposure, de meeste integratiecomplexiteit en de hoogste verwachtingen van eindgebruikers. Als dat systeem stil faalt (antwoorden die kloppen noch foutmelding geven), daalt het vertrouwen in AI voor de volgende twee jaar.

De oorzaak ligt niet bij de technologie. De oorzaak is dat het fundament ontbreekt: geen logging, geen eigenaarschap, geen evaluatiecriteria. Die zijn onzichtbaar en leveren geen demo op. Maar ze bepalen alles.

Waarom roadmaps stil falen

Een roadmap die bestaat uit een lijst van wat AI “gaat doen” heeft één structureel probleem: hij maakt geen onderscheid tussen fundament en features. Features zijn zichtbaar: een systeem dat samenvat, een agent die vragen beantwoordt. Het fundament is onzichtbaar: de logging die je vertelt wanneer het systeem begint af te wijken, het eigenaarschapsmodel dat bepaalt wie er ’s nachts gebeld wordt als het fout gaat, de evalset die definieert wat “correct” eigenlijk betekent.

Zonder fundament gaat het eerste systeem live. Het lijkt te werken. Een paar weken later merkt iemand dat de outputs vreemder worden. Niemand weet precies wanneer het begon. Niemand weet wie het moet oplossen. Het systeem wordt stilgezet of genegeerd. Het vertrouwen daalt.

De weg uit die val is niet meer technologie. Het is volgorde.

Het kwadrantenmodel: waar begin je?

Voordat je een tijdlijn uitzet, heb je een selectiecriterium nodig. Twee assen zijn daarvoor voldoende:

As 1: Waarde voor de organisatie. Hoeveel tijd, geld of kwaliteit levert het op? As 2: Technische en organisatorische complexiteit. Hoeveel integratie, risico en afstemming vraagt het?

Begin rechtsonder: hoge waarde, lage complexiteit. Dat zijn de use cases die snel vertrouwen opbouwen zonder dat een mislukking grote schade aanricht. Vermijd linksboven: lage waarde, hoge complexiteit. Die kosten de meeste energie en leveren het minste op.

Klantgerichte systemen met real-time beslissingen zitten bijna altijd rechtsboven: hoge waarde, maar ook hoge complexiteit. Dat zijn niet onmogelijke use cases; ze horen thuis in kwartaal 2, 3 of 4, als het fundament er al staat.

De vier kwartalen

Kwartaal 1: Fundament leggen

Kies één interne use case met lage risico-exposure (geen klantdata, geen kritieke besluiten). Goede voorbeelden: een interne FAQ-bot voor HR-vragen, samenvattingen van vergadernotulen, eerste drafts van standaarddocumenten. De waarde is reëel maar beperkt; dat is precies wat je wilt in het eerste kwartaal.

Bouw de infrastructuur die elk volgend systeem nodig heeft: logging en observability vóór de launch, niet erna. Definieer eigenaarschap (wie is verantwoordelijk als het systeem faalt, en wat is het protocol?). Geen klantgerichte productie-launch in kwartaal 1.

Kwartaal 2: Eerste productie-use case

Kies uit je kwadrant de use case met de beste verhouding tussen waarde en complexiteit. Bouw een evalset op: 20 tot 50 scenario’s die beschrijven wat correct gedrag is. Dit klinkt als overhead, maar het is het enige instrument waarmee je kunt beoordelen of het systeem verbetert of verslechtert.

Launch in beperkte productie: één team, één klantgroep, of één proces. Monitor kosten per taak en foutpercentage; volg ook de escalatierate. Als je in kwartaal 2 een klantgericht systeem lanceert, begin dan hier ook met je transparantiedocumentatie in het kader van de EU AI Act. Let op: de transparantieverplichting voor systemen die interageren met mensen geldt al sinds 2 augustus 2026. Wie dat documentatietraject pas in kwartaal 4 start, werkt te laat.

Kwartaal 3: Schaal en leer

Breid de eerste use case uit op basis van wat je in productie hebt geleerd, niet op basis van wat je in kwartaal 1 verwachtte. Begin tegelijkertijd met een tweede use case, nu met de patronen en fouten van kwartaal 2 als startpunt.

Doe de eerste eerlijke evaluatie: welke aannames waren onjuist? Wat kostte meer dan begroot? Investeer in een gedeelde kennisbasis voor het team. Een team dat dezelfde fouten herhaalt op het tweede systeem heeft geen technisch probleem, maar een kennisinfrastructuurprobleem.

Kwartaal 4: Systematiseer

Codificeer wat werkt: evaluatie-templates, logging-standaarden, het eigenaarschapsmodel. Zorg dat het overdraagbare kennis is, niet bureaucratie. Het volgende systeem mag niet opnieuw beginnen bij nul.

Stel de roadmap op voor het volgende jaar op basis van wat je nu weet, niet op basis van wat je 12 maanden geleden dacht te weten. Rapporteer aan stakeholders met concrete getallen: ROI per use case, werkelijke kosten versus schatting, capaciteitsplan voor het team.

Wat niet in je roadmap hoort

Drie patronen die een roadmap ondermijnen:

Een use case opnemen zonder plan voor de evalset. Zonder een definitie van correct gedrag kun je geen ROI berekenen, geen kwaliteitsregression detecteren en geen verantwoording afleggen.

Een use case opnemen zonder basislijnmeting. Als je niet weet hoe lang een taak nu duurt of hoeveel fouten er nu in zitten, kun je na de implementatie niets bewijzen.

Een systeem opnemen waarbij niemand eigenaarschap heeft in geval van falen. “Het team” is geen eigenaar. Een naam is een eigenaar.

De EU AI Act als planningsinstrument

De transparantieverplichting is nu al van kracht. Systemen die live gaan en interageren met mensen, vallen sinds 2 augustus 2026 onder deze verplichtingen. Dat betekent: documenteer in kwartaal 2 al welke systemen in scope zijn, wat ze doen, en hoe je gebruikers informeert. Wie dat in kwartaal 4 probeert toe te voegen aan een systeem dat al in productie draait, heeft een hardere opdracht dan wie het van het begin meebouwt.

De AI Act maakt van compliance een planningsfactor, niet een afvinklijst achteraf.


De workshops voor leaders werken dit model uit aan de hand van je eigen systemen en sector. Bekijk het programma op /workshops/leaders.