Een AI-roadmap voor de komende 12 maanden

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 u wilt bouwen. Het is een volgorde van capaciteiten die u 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 uw 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 u 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 begint u?

Voordat u een tijdlijn uitzet, hebt u 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. Die zijn niet onmogelijk — ze zijn voor kwartaal twee, drie of vier, 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 u 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 dan het protocol? Geen klantgerichte productie-launch in kwartaal 1.

Kwartaal 2: Eerste productie-use case

Kies uit uw 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. Dat klinkt als overhead — het is het enige instrument waarmee u kunt beoordelen of het systeem verbetert of verslechtert.

Launch in beperkte productie: één team, één klantgroep, of één proces. Monitor kosten per taak, foutpercentage en escalatierate. Als u in kwartaal 2 een klantgericht systeem lanceert, begin dan hier ook met uw transparantiedocumentatie in het kader van de EU AI Act. De deadline voor transparantieverplichtingen bij systemen die interageren met mensen is augustus 2026; wie dat documentatietraject in kwartaal 4 start, werkt te laat.

Kwartaal 3: Schaal en leer

Breid de eerste use case uit op basis van wat u in productie hebt geleerd — niet op basis van wat u 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. Niet als bureaucratie, maar als overdraagbare kennis. Het volgende systeem mag niet opnieuw beginnen bij nul.

Stel de roadmap op voor het volgende jaar op basis van wat u nu weet — niet op basis van wat u twaalf 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 uw roadmap hoort

Drie patronen die een roadmap ondermijnen:

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

Een use case opnemen zonder basislijnmeting. Als u niet weet hoe lang een taak nu duurt of hoeveel fouten er nu in zitten, kunt u 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

Augustus 2026 is geen verre deadline meer. Systemen die na die datum live gaan en interageren met mensen vallen onder transparantieverplichtingen. Dat betekent: documenteer in kwartaal 2 al welke systemen in scope zijn, wat ze doen, en hoe u 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 uw eigen systemen en sector. Bekijk het programma op /workshops/leaders.

Publicatienota’s

Angle: Diagnostic / decision guide — de stille-faling-trap als ingang, kwadrantenmodel als structuurgereedschap.

Lezerbelofte: Een CTO of IT-manager verlaat dit artikel met een concrete volgorde en drie concrete uitsluitingscriteria voor hun roadmap.

Bewijskloof: De EU AI Act-deadline (augustus 2026) is behandeld als een beleidsmatig gegeven; geen primaire bronverwijzing opgenomen — menselijke verificatie aanbevolen voor publicatie als de exacte datum load-bearing is in uw communicatie.

Claims die verificatie verdienen: De specifieke datum “augustus 2026” voor de EU AI Act transparantieverplichtingen is afkomstig uit het source packet; verifieer met de officiële EU AI Act-tekst (Artikel 50, toepassing GPAI-modellen en interactieve systemen) vóór publicatie.

Alternatieve koppen:

• “Uw AI-roadmap fout beginnen is duurder dan u denkt”
• “AI uitrollen in vier kwartalen: fundament eerst”
• “Waarom uw AI-roadmap geen lijst van systemen mag zijn”