Elke tweede CTO stelt vandaag dezelfde vraag: "Waar begin je met AI zonder dat het opnieuw een nutteloze investering wordt?" Het antwoord zit niet in de technologie. Het zit in de discipline van de eerste drie maanden — wat u in kaart brengt, wat u afwijst, wie u verantwoordelijk maakt en hoe u het resultaat meet. Dit artikel is een beslissingskader voor de eerste 90 dagen, geen technische installatiegids voor een model.
De meeste bronnen melden dat 75–95 % van de AI-projecten de geplande bedrijfswaarde niet haalt. De methodologie van de studies laat wellicht ruimte voor discussie, maar de trend is consistent: pilots worden gestart, eindigen na 3–6 maanden en leveren geen waarde op. De oorzaak is steevast dezelfde — niet slechte technologie, maar ontbrekende voorbereiding vóór het eerste import openai.
Dag 1–30: Breng het terrein in kaart voor u gaat graven
Inventariseer use-cases, geen aankooplijst
De eerste maand gaat niet over het kiezen van technologie. Het gaat over begrijpen waar het bedrijf tijd en geld verliest aan repetitieve cognitieve taken — documenten lezen, steeds dezelfde vragen beantwoorden, gegevens uit formulieren halen, standaardrapporten schrijven.
Een snelle aanpak: vraag 5–10 mensen uit verschillende afdelingen op papier te noteren wat ze elke week herhaaldelijk doen en wat hen ergert. Het merendeel van wat ze opschrijven zal categorisch anders zijn dan "we willen een chatbot". Het zal zijn: handmatig overschrijven van klantmails naar het CRM, antwoorden zoeken in technische documentatie, offerteonderlagen voorbereiden, vrachtbrieven controleren.
Beoordeel elke use-case op twee assen: frequentie (hoe vaak het voorkomt) en waarde (wat één uitvoering kost — tijd × uurtarief × aantal herhalingen per maand). Dit is geen academische oefening — het is de basis voor het ROI-gesprek dat u over 60 dagen met het management voert.
Onderscheid: chatbot, copilot of agent
Bepaal vóór de toolselectie wat u eigenlijk nodig hebt. Chatbot, copilot en agent zijn verschillende architectuurpatronen met verschillende kosten en complexiteit.
Chatbot beantwoordt vragen — geschikt voor klantenservice of interne FAQ. Het eenvoudigst te implementeren, de laagste verwachtingen.
Copilot assisteert een medewerker in zijn eigen tool — in een productie-MES-systeem, in ERP, in documentatie. De medewerker neemt beslissingen, AI stelt voor en bereidt voor. De typische eerste stap voor industriële bedrijven.
Agent plant, roept tools aan en voert meerstapsacties autonoom uit. Krachtiger, maar veelvoudig complexer — vereist error handling, observability en grondig piloting. Niets voor het eerste project.
Voor 80 % van de bedrijven in de eerste 90 dagen is het juiste antwoord: een copilot over interne documentatie of RAG over de bedrijfs-KB.
Data: open de doos van Pandora meteen
AI-projecten mislukken op data, niet op modellen. Kom in de eerste maand te weten:
- Waar bevinden zich documenten, handleidingen, technische voorschriften, serviceregistraties — en in welk formaat (PDF, Word, tabellen, databases)?
- Wie heeft toegang? Is de gevoeligheid van de data bepaald (GDPR, bedrijfsgeheimen)?
- Hoe actueel zijn de gegevens — zijn documenten bijgewerkt of stammen ze uit 2018?
De Cisco AI Readiness Index meldt dat slechts ~34 % van de bedrijven hun databereidheid als voldoende beoordeelt. In de praktijk betekent dit: gescande archief-PDF's, handmatig gecodeerde Excel-tabellen en documentatie die alleen in het hoofd van oudgedienden zit. Dat is geen reden om niet te beginnen — het is een reden om te beginnen met een data-audit, niet met een model.
Dag 31–60: Een pilot die iets beslecht
De eerste use-case kiezen: ROI-positief, niet het meest verleidelijk
De meest voorkomende fout: een bedrijf kiest de meest ambitieuze use-case — "we willen AI voor het voorspellen van storingen op de productielijn" — en de pilot loopt vast op onvoldoende historische data, een onduidelijk succescriterium en een ontbrekende domeinexpert.
De eerste use-case moet gelijktijdig aan drie voorwaarden voldoen:
- 1.Meetbare baseline — u weet hoeveel uren de betreffende taak nu kost. Zonder baseline kunt u het resultaat niet evalueren.
- 2.Afgebakende scope — de pilot past in 4–6 weken inclusief evaluatie. Hoe langer de pilot, hoe kleiner de kans dat hij de eindstreep haalt.
- 3.Reëel datafundament — u beschikt over minimaal 50–200 documenten of transacties waarmee u de pilot kunt testen. Geen toekomstige database.
Een goede eerste use-case voor een productiebedrijf: Q&A over technische documentatie (RAG over servicehandleidingen, certificaten, normen). Technici zoeken tien keer per dag dezelfde antwoorden, er is voldoende documentatie en de meetbaarheid is helder (zoektijd vóór vs. na).
Pilotarchitectuur: lokaal of cloud?
Voor bedrijven met gevoelige technische documenten of regelgevingsdruk (machineenbouw, chemische industrie, gezondheidszorg) is de eerste vraag: "Mag onze data het netwerk verlaten?"
Als dat niet mag — een lokaal model (Ollama met Qwen 3 of Mistral, draaiend op een bedrijfsserver of workstation) met een lokale vectordatabase is de juiste keuze. De prestaties zijn lager dan een frontier cloud-model, maar het compliance-risico is nul.
Als dat wel mag — cloud API (Claude Sonnet, GPT, Gemini Flash) met Azure OpenAI of rechtstreeks via API levert betere out-of-the-box prestaties bij een lagere IT-last in de pilotfase.
Een gedetailleerdere vergelijking vindt u in het artikel Lokale LLM vs. cloud en ook in de discussie RAG vs. fine-tuning — wanneer wat.
Succescriteria vóór de start van de pilot
Bepaal wat succes is, vóór de pilot. Niet erna. Typische metrics:
- Tijdsbesparing per taak — doel: -30 % of een concreet aantal minuten
- Nauwkeurigheid van antwoorden — doel: >85 % correcte antwoorden bij beoordeling door een domeinexpert (20–50 testvragen)
- Gebruikersadoptie — doel: >60 % van de teamleden gebruikt het systeem minimaal 3× per week na 4 weken
- Foutpercentage — doel: <5 % van de antwoorden bevat feitelijk onjuiste informatie
Zonder deze cijfers eindigt de pilot in een debat "werkt het?" in plaats van data die met ja of nee antwoordt.
Dag 61–90: Resultaten, beslissing, plan
Pilotevaluatie: drie vragen
Na 4–6 weken pilot beantwoordt u drie vragen:
1. Werkt het goed genoeg? Vergelijk met de pre-pilotbaseline. Heeft u het doel gehaald — ga door. Zo niet — waarom niet? Data, prompt, integratie of was de use-case de verkeerde keuze?
2. Adopteren mensen het? Een technisch werkend systeem dat niemand gebruikt heeft geen bedrijfswaarde. Adoptie in de eerste weken voorspelt het langetermijnresultaat. Is de adoptie laag, zoek uit waarom — UI, vertrouwen, training of bespaart het systeem simpelweg geen tijd?
3. Waar zit de grootste weerstand? Elk AI-project stuit op "dat werkt toch niet". Bepaal waar de weerstand vandaan komt — IT-beveiliging (data), middenmanagement (controle), medewerkers (angst voor baanverlies). Elk heeft een ander antwoord.
ROI-berekening: eenvoudig, maar eerlijk
Voor beslissers die de voortzetting moeten verdedigen, heeft u cijfers nodig. ROI van AI-projecten meten is een apart onderwerp, maar het basisraamwerk:
- Tijdsbesparing: (aantal uren/maand bespaard) × (uurtarief medewerker) × 12 = jaarwaarde
- Projectkosten: infrastructuur + API-kosten + ingenieurstijd (pilot + productie)
- Terugverdientijd: kosten / maandwaarde = aantal maanden tot terugverdienen
Voor een typische RAG-copilot bij 5–10 technische medewerkers met een besparing van 30–60 minuten per dag: de jaarwaarde is meetbaar in tientallen duizenden euro's bij Midden-Europese uurtarieven. De pilotkosten liggen in de orde van 10–30 keer lager als u bestaande infrastructuur en enkele dagen ingenieurswerk inzet.
Build vs. buy: de beslissing op dag 90
Na de pilot beschikt u over voldoende data voor de build vs. buy-beslissing. De vuistregel uit de praktijk:
Koop (SaaS-tool, geïntegreerde plugin) als: de use-case generiek is (klantenservice, samenvatting van e-mails), er geen kritische differentiatie speelt en het team geen AI-engineeringcapaciteit heeft.
Bouw (eigen RAG-pipeline, eigen agent) als: de data gevoelig is en niet naar de cloud mag, de use-case domeinspecifiek is (machinenormen, interne processen), of u schaalbaarheid naar meer use-cases plant waarbij gedeelde componenten (embedding, vectordatabase, orchestratie) de moeite waard zijn om te delen.
Combineer — het meest voorkomende juiste antwoord in 2026: koop voor commodity-lagen (model API, vector DB), bouw voor de "laatste mijl" (prompts, retrievallogica, integraties, eval harness).
Wat u moet vermijden: vijf valkuilen in de eerste 90 dagen
1. Hype-use-case zonder baseline
"We willen voorspellend onderhoud" of "we willen een AI-strateeg" — ambitieus, visueel aantrekkelijk en bij nader inzien zonder meetbare baseline, zonder historische data en zonder domeinexpert in het team. Deze projecten sterven in de derde maand.
Vuistregel: als u geen baseline heeft, heeft u een ambitie, geen project.
2. Vendor lock-in in de pilotfase
Sommige leveranciers bieden een "gratis pilot" in ruil voor een commitment. Voordat u tekent: test een alternatief — een open-source stack (LangChain/LlamaIndex + Qdrant + lokaal model) kan de meeste pilots uitvoeren zonder verplichtingen. Vendor lock-in is verstandig na validatie van de use-case, niet ervóór.
3. AI-team zonder domeinexpert
Een AI-ingenieur kan een pipeline bouwen. Hij kan niet beoordelen of een antwoord over een hydraulisch circuit correct is. Zonder een technicus of technoloog die de outputs in de pilot valideert, heeft u geen basis voor het meten van nauwkeurigheid. Een domeinexpert is geen "nice to have" — het is een blocker.
4. Eén pilot = productiestrategie
Pilots bewijzen het principe, niet de productiegereedheid. Van pilot naar productie zijn nodig: een beveiligingsaudit (prompt injection, data egress), MLOps (monitoring, promptversiebeheer, eval regression) en change management (gebruikerstraining, SLA, escalatiepad als AI een fout antwoord geeft).
5. EU AI Act negeren
Als uw use-case in een beslissingsketen belandt met impact op mensen (werving, beoordeling, risicoclassificatie), gelden vanaf 2 augustus 2026 de transparantie- en risicoklassificatievereisten van de EU AI Act. Compliance is niet alleen een juridische oefening — het beïnvloedt de systeemarchitectuur (auditlog, explainability, menselijk toezicht). Hoe vroeger u dit in het ontwerp meeneemt, hoe goedkoper de aanpassing.
Team: wie u nodig heeft en wie niet
Een AI-project is geen solowerk. Een productiesysteem (niet alleen een pilot) vereist doorgaans een combinatie van:
- AI/ML-ingenieur — RAG-pipeline, fine-tuning, agentorkestratie, eval
- Data-ingenieur — datapipeline, opschoning, vectordatabase
- Domeinexpert — validatie van outputs, opstellen van de eval-set
- Product owner — succesmetrics, prioritering van use-cases, stakeholder management
- IT/beveiliging — data egress, toegangsbeheer, compliance
Voor de pilotfase is de volledige bezetting niet nodig. AI-ingenieur + domeinexpert + product owner kunnen de pilot aan. MLOps en data-ingenieur komen bij de overgang naar productie.
Waarschuwing: een team van minder dan 3 personen die verantwoordelijk zijn voor een AI-project is risicovol, zelfs voor een pilot. Één uitval van een sleutelpersoon stopt het hele proces.
Intern team vs. externe partner hangt af van de strategie: als AI een langetermijncompetentie van het bedrijf is, bouw dan intern. Als u snel 2–3 use-cases wilt valideren en geen AI-capaciteit heeft, is een externe partner met een vaste projectstructuur sneller. De combinatie — externe partner piloteert, intern team neemt de productie over — is een verstandig hybride model.
Meten na 90 dagen: vier vragen voor de retrospectief
Aan het einde van de eerste 90 dagen beantwoordt u eerlijk:
- 1.Heeft de pilot de succescriteria gehaald die we vóór de start hebben vastgelegd? (Als u die niet heeft vastgelegd — dat is op zichzelf al een les.)
- 2.Kunnen we 2–3 verdere use-cases benoemen waarbij dezelfde infrastructuur extra waarde oplevert? (Zo niet — er bestaat een risico dat we piloteren zonder strategie.)
- 3.Heeft het project een sponsor op directieniveau die de bedrijfswaarde kan formuleren? (Projecten zonder CEO/COO-sponsor falen historisch gezien statistisch aanzienlijk vaker dan die met een sponsor.)
- 4.Weten we hoe het systeem er in productie uitziet — monitoring, eval, updatecyclus? (Zo niet — de pilot is een proof-of-concept, geen basis voor schaling.)
Deze vier vragen beoordelen niet de technologie. Ze beoordelen de organisatiegereedheid — en die bepaalt het resultaat meer dan welk model dan ook.
Veelgestelde vragen
Wat kost dit allemaal — de eerste 90 dagen?
Dat hangt af van de scope, maar als indicatie: een pilot met een RAG-copilot over interne documentatie, op cloud API, met een externe partner — in de orde van enkele duizenden euro's aan ingenieursuren plus lage maandelijkse API-kosten (voor kmo's doorgaans tientallen tot honderden euro's bij normaal volume). Een lokale implementatie (eigen server, open-weight model) heeft een hogere eenmalige instapkost, maar lagere operationele kosten.
Hebben we een eigen GPU nodig?
Voor de pilotfase doorgaans niet. Cloud API (Claude, Gemini Flash, GPT) of Ollama op een bestaande bedrijfsserver met een gewone CPU is voldoende voor de pilot. Een eigen GPU heeft zin als: data niet naar de cloud mag, het inferentievolume hoog is (duizenden verzoeken per dag), of u fine-tuning plant.
Wat als onze data niet klaar is?
Dataongereedheid is geen blocker voor een pilot — het is een inputparameter. Een pilot op 50 goed voorbereide documenten is beter dan een pilot op 5.000 slechte. Begin met een gouden set van 50–100 documenten die u handmatig controleert. Productief schalen regelt u na validatie van de use-case.
Hoe leggen we medewerkers uit dat we AI invoeren?
Direct en concreet — niet "AI neemt uw baan over", maar "AI neemt het zoeken in handleidingen over, zodat u meer tijd heeft voor het oplossen van problemen". Betrek medewerkers bij de pilot als "AI-evaluatoren" — hun rol is testen en fouten rapporteren. Ownership van de pilot vermindert de weerstand bij de overgang naar productie.
Is het beter te beginnen met één groot project of meerdere kleine pilots?
Uit de praktijk: één goed gekozen pilot met een helder ROI is beter dan drie gelijktijdige experimenten. Parallelle pilots versnipperen de aandacht, verminderen de datakwaliteit voor elk van hen en bemoeilijken de evaluatie. Schaal naar meer use-cases na de eerste successen — niet ervóór.
*MP Industrial Solutions helpt bedrijven de eerste 90 dagen gestructureerd te doorlopen — van de inventarisatie van use-cases via de keuze van de architectuur tot de definitie van meetbare succescriteria. Als u overweegt waar te beginnen en pilotprojecten wilt vermijden die op niets uitlopen, plannen wij graag een gratis oriëntatiegesprek.*