Het plannen van een IT-project brengt van nature onzekerheden met zich mee, maar bij het implementeren van kunstmatige intelligentie (AI) en Large Language Models (LLM's) lopen tijdslijnen stelselmatig verder uit dan voorzien. Waar traditionele software-ontwikkeling grotendeels draait om het bouwen van van tevoren gedefinieerde functionaliteiten, kenmerkt een AI-traject zich door experiment, iteratie en sterke afhankelijkheid van externe randvoorwaarden.
In dit artikel ontleden we de tijdsfactor binnen B2B AI-projecten. We kijken niet naar de geschatte ontwikkeluren van een algoritme, maar naar de werkelijke doorlooptijd die de organisatie doormaakt. Het accent ligt bewust op de fasen en organisatorische fricties die in initiële planningen vrijwel altijd worden onderschat.
Waarom de tijdslijn van AI-projecten afwijkt
Een veelvoorkomende valkuil bij het opstellen van een projectplanning is de aanname dat de technische oplevering gelijkstaat aan het einde van het project. Een AI-model dat lokaal of op een testomgeving naar behoren functioneert, representeert vaak slechts een fractie van de totale doorlooptijd.
De werkelijke vertragingen ontstaan niet door het schrijven van de code zelf, maar door de interactie tussen de technologie en de bestaande organisatie. Het ophalen van de juiste data, het verkrijgen van juridische akkoorden en het aanpassen van de werkwijze van medewerkers duren in de praktijk vele malen langer dan het bouwen van de technische koppeling.
De acht structureel onderschatte fasen
Om tot een realistische doorlooptijd te komen, moet het gehele traject worden opgeknipt in fasen. Onderstaande tijdsindicaties moeten worden gezien als een algemene vuistregel (geen empirische meting of vaste norm) en zijn sterk afhankelijk van de organisatiegrootte en de complexiteit van het domein.
1. Toegang tot data en systemen regelen
Het verkrijgen van API-sleutels, database-toegangen en benodigde autorisaties binnen een enterprise-omgeving is zelden een kwestie van uren. Vaak moeten er interne tickets geopend worden, moeten securityteams goedkeuring geven en moeten service level agreements (SLA's) met interne beheerders worden afgestemd. Vuistregel voor doorlooptijd: 2 tot 6 weken.
2. Datakwaliteit opschonen en structureren
Een model is zo goed als de data die wordt aangeleverd. Het opschonen van ongestructureerde documenten, het corrigeren van incomplete metadata en het consolideren van versnipperde kennisbronnen vergt intensieve handenarbeid en afstemming. Voor een diepgaandere blik op deze stap kunt u ons artikel over datakwaliteit voor AI raadplegen. Vuistregel voor doorlooptijd: 3 tot 8 weken.
3. Security- en privacyreview (DPIA)
Wanneer bedrijfsspecifieke gegevens door een AI-model worden verwerkt, zijn gegevensbescherming en privacy van cruciaal belang. Het uitvoeren van een Data Protection Impact Assessment (DPIA) en de beoordeling door een Data Protection Officer (DPO) of Security Board vertraagt de start van de daadwerkelijke bouw aanzienlijk. Zie voor verdere details onze handleiding over de AI-risicoanalyse en DPIA. Vuistregel voor doorlooptijd: 4 tot 10 weken.
4. Inkoop en contractvorming
Het afsluiten van SaaS-contracten, verwerkersovereenkomsten (VWO) of het aanschaffen van dedicated compute-capaciteit vereist betrokkenheid van de juridische afdeling en de inkoopafdeling. Onderhandelingen over aansprakelijkheid, datalocaties en IP-rechten kosten veel tijd. Vuistregel voor doorlooptijd: 3 tot 8 weken.
5. Evaluatie opzetten en valideren
Hoe weet u of de uitvoer van de AI correct, veilig en nuttig is? Het bouwen van een robuuste evaluatieset (golden dataset) met handmatig gecontroleerde voorbeelden vraagt constante afstemming met vakinhoudelijke experts. Zie ook het kader over het zelf evalueren van AI-systemen op ons benchmarkplatform. Vuistregel voor doorlooptijd: 2 tot 5 weken.
6. Integratie in bestaande processen en software
Het AI-model moet landen in de dagelijkse workflow van medewerkers, bijvoorbeeld binnen het CRM- of ERP-systeem. Dit vraagt om maatwerk-API-koppelingen, het inrichten van een beheeromgeving en monitoring. Meer over de technische monitoring leest u bij observability en logging op ons API-platform. Vuistregel voor doorlooptijd: 4 tot 8 weken.
7. Gebruikerstraining en verandermanagement
Eindgebruikers moeten leren vertrouwen op het systeem, maar ook de limieten ervan begrijpen. Het organiseren van werksessies, het opstellen van prompt-richtlijnen en het opvangen van weerstand vragen om een gefaseerde uitrol. Vuistregel voor doorlooptijd: 2 tot 6 weken.
8. Beheer na oplevering en modelonderhoud
Na de livegang stopt het project niet. Modellen vereisen continue monitoring op 'drift', veranderende brondocumenten en feedback van gebruikers. De overdracht van het projectteam naar een staande beheerorganisatie kost tijd. Vuistregel voor doorlooptijd: 2 tot 4 weken.
| Projectfase | Indicatieve doorlooptijd (Vuistregel) | Primaire vertragingsfactor |
|---|---|---|
| 1. Toegang & Authorisaties | 2 - 6 weken | Interne IT-tickets, rechtenstructuur |
| 2. Datakwaliteit & Opschoning | 3 - 8 weken | Ontbrekende metadata, vervuilde bronnen |
| 3. DPIA & Security Review | 4 - 10 weken | Juridische toetsing, privacy-kaders |
| 4. Inkoop & Contractering | 3 - 8 weken | Onderhandelingen VWO en aansprakelijkheid |
| 5. Evaluatieset Opzetten | 2 - 5 weken | Beschikbaarheid van domeinexperts |
| 6. Systeemintegratie | 4 - 8 weken | Legacy API's, release-cycles |
| 7. Gebruikerstraining | 2 - 6 weken | Verandercapaciteit van de organisatie |
| 8. Beheeroverdracht | 2 - 4 weken | Inrichten van monitoring en support |
Organisatorische vertragingsfactoren (Niet-technisch)
Uit ervaring blijkt dat de werkelijke vertragingen in meer dan 70% van de gevallen toe te schrijven zijn aan de organisatie en niet aan de gebruikte technologie. Een strak geschreven algoritme staat stil als de organisatie niet meebeweegt.
- Wachten op goedkeuringen: Veel projecten kennen afhankelijkheden van stuurgroepen die slechts eens per maand vergaderen. Eén gemiste beslisronde schuift de gehele planning direct vier weken op.
- Beschikbaarheid van domeinexperts: De vakspecialisten die de uitvoer van de AI moeten beoordelen en valideren, hebben vaak al een volledige werkweek aan reguliere operationele taken. Hun schaarse tijd vormt snel een bottleneck.
- Changefreeze-periodes: In veel organisaties gelden strikte periodes waarin geen veranderingen aan productiesystemen mogen worden doorgevoerd (bijvoorbeeld rond de feestdagen of aan het einde van een kwartaal).
- Vakantieperiodes: De zomer- en kerstvakanties zorgen voor een vertraging die verder gaat dan alleen de afwezigheid van medewerkers; het hervatten van de besluitvorming duurt vaak dubbel zo lang.
Sturen op beslismomenten en bandbreedtes
Het hanteren van een strakke, lineaire planning met een vaste einddatum leidt bij AI-projecten vrijwel gegarandeerd tot teleurstelling. Een realistischer alternatief is het plannen op basis van beslismomenten (go/no-go fasen) en het hanteren van een bandbreedte in plaats van een harde opleverdatum.
In plaats van te beloven dat een systeem op 1 oktober live gaat, communiceert de projectleiding bijvoorbeeld een bandbreedte: "Go-live vindt plaats tussen week 40 en week 44, afhankelijk van de goedkeuring van de DPIA in fase 3."
Aanname: We nemen aan dat het management bereid is om op basis van gefaseerde goedkeuring te sturen, in plaats van te vasthouden aan een rigide, vooraf vastgestelde einddatum.
Na elke fase wordt het project geëvalueerd. Blijkt dat de datakwaliteit onvoldoende is om de gestelde nauwkeurigheid te behalen, dan wordt de optie ingezet om eerst de data te herstellen voordat de integratiefase start. Meer over deze gefaseerde aanpak leest u in ons artikel over de AI-pilot in 30 dagen en de uitgebreide toelichting over de overgang van pilot naar productie.
Signalen dat een planning faalt
Een projectplanning loopt zelden van de ene op de andere dag volledig vast; het is een geleidelijk proces. Er zijn een aantal vroegtijdige signalen die erop wijzen dat de geplande doorlooptijd niet meer realistisch is:
- Onbeantwoorde vragen bij de juridische afdeling: Ligt een conceptovereenkomst of DPIA langer dan twee weken zonder inhoudelijke terugkoppeling bij Security of Legal? Dan is vertraging onafwendbaar.
- Overschrijding van de feedbacktermijn door domeinexperts: Lukt het de inhoudelijk deskundigen niet om binnen de afgesproken termijn de model-outputs te valideren? Dit is de eerste indicator voor een stagnatie in fase 5.
- Aannames over data-beschikbaarheid blijken onjuist: Zodra blijkt dat data handmatig uit PDF-bestanden gehaald moet worden in plaats van via een direct toegankelijke API, vervalt de oorspronkelijke tijdsinschatting. Raadpleeg voor het goed afbakenen van het project onze leidraad voor AI-project scoping.
- Het verschuiven van testmilieus: Als het opzetten van de test- of acceptatieomgeving herhaaldelijk wordt uitgesteld vanwege IT-beheerprioriteiten, komt de integratiefase onder druk te staan.
Checklist: Vragen vooraf voor een realistische planning
Stel onderstaande vragen voordat de definitieve tijdslijn van het AI-project wordt vastgesteld. Een ontkennend antwoord geeft direct aan op welk vlak extra doorlooptijd moet worden ingeruimd.
- [ ] Is er al een goedgekeurd verwerkerscontract aanwezig voor de beoogde AI-leverancier of het cloudplatform?
- [ ] Is de Privacy Officer / DPO aangehaakt en is er tijd ingeruimd in hun kwartaalplanning voor een DPIA?
- [ ] Zijn de benodigde gegevens direct via een gedocumenteerde API toegankelijk, of moeten er nog exports gemaakt worden?
- [ ] Zijn de inhoudelijke domeinexperts formeel vrijgesteld voor een vast aantal uren per week om het systeem te valideren?
- [ ] Is bekend wanneer de geplande release-windows en eventuele changefreezes van de omliggende IT-systemen plaatsvinden?
- [ ] Is het besluitvormingsorgaan (stuurgroep) ingericht om op basis van gefaseerde beslismomenten besluiten te nemen?
Door bij het opstellen van het AI-implementatieplan rekening te houden met deze organisatorische werkelijkheid, voorkomt u verrassingen en bouwt u aan een voorspelbaar, beheersbaar traject.
