AI-roadmaps worden minder modelkeuze en meer afhankelijkhedenmanagement

Waarom modelnieuws niet hetzelfde is als roadmapnieuws

AI-teams krijgen in hoog tempo nieuwe modelnamen, contextclaims, agentfuncties en infrastructuursignalen op hun bord. In één week kunnen er updates langskomen rond modellen zoals Anthropic Sonnet 4.6, Google Gemini 3.1 Pro en xAI Grok 4.2 beta, plus tools rond computerbediening en multi-agent coördinatie. Dat is relevant, maar het is nog geen roadmap. Een roadmap gaat niet over de vraag welk merk het meeste aandacht krijgt. Een roadmap gaat over welke workload je betrouwbaar, betaalbaar en bestuurbaar in productie wilt brengen.

Daarom is de nuchtere vraag voor AI-leads, CTO’s en productteams: welke afhankelijkheden ontstaan zodra we deze mogelijkheden serieus meenemen? Long context kan aantrekkelijk zijn, maar verandert je evaluatie-aanpak. Agent-tools kunnen waardevol zijn, maar verhogen de foutkosten als ze echte handelingen uitvoeren. Compute-intensieve workflows kunnen productwaarde leveren, maar maken planning gevoeliger voor prijs, capaciteit en leverancierskeuze. Wie alleen naar de modelupdate kijkt, mist de keten eromheen.

Een houdbare AI-roadmap begint dus niet bij het scorebord. Hij begint bij het werk dat gedaan moet worden. Moet een model lange dossiers verwerken, meerdere databronnen combineren, code aanpassen, een workflow bedienen of alleen een goed conceptvoorstel schrijven? Pas als die vraag scherp is, kun je modelkeuze, agentniveau, infrastructuur en governance verstandig beoordelen.

Van modelbenchmark naar productbeslissing

Modelbenchmarks en productdemo’s zijn nuttige signalen, maar ze zijn zelden direct genoeg voor een implementatiebesluit. Een model dat indrukwekkend scoort op een publieke taak hoeft niet automatisch het beste model te zijn voor jouw documenten, jouw gebruikers, jouw fouttolerantie of jouw kostenstructuur. Dat geldt zeker wanneer de roadmap gaat over bedrijfsprocessen waarin output gecontroleerd, gelogd en reproduceerbaar moet zijn.

Vertaal modelnieuws daarom naar een workloadkaart. Per use-case noteer je minimaal zeven punten: contextlengte, multimodaliteit, latency, kosten, evaluatie, fallback en governance. Contextlengte gaat niet alleen over hoeveel tokens een model aankan, maar ook over de vraag of het model de relevante informatie in lange input consistent gebruikt. Multimodaliteit is alleen belangrijk als beeld, audio of documentstructuur daadwerkelijk onderdeel is van de taak. Latency bepaalt of de workflow geschikt is voor realtime gebruik of beter als batchproces draait.

Kosten vragen meer dan een prijs per token. Je wilt weten wat een volledige taak kost inclusief retries, evaluaties, logging en menselijke controle. Evaluatie vraagt om eigen testsets, niet alleen om algemene benchmarkverwijzingen. Fallback betekent dat je vooraf bepaalt wat er gebeurt als een model traag, duur, onbeschikbaar of onvoldoende betrouwbaar is. Governance betekent dat je kunt uitleggen wie verantwoordelijk is voor prompts, data, toestemming, outputcontrole en wijzigingsbeheer.

Als je Sonnet, Gemini, Grok of een ander model naast elkaar zet, doe dat dan niet als ranglijst maar als fit-per-taak. Voor een lange juridische samenvatting kunnen andere eisen gelden dan voor code-assistentie, supporttriage of marketingvarianten. Een modelkeuze wordt pas professioneel als je kunt zeggen: voor deze workload accepteren we deze latency, deze kostenbandbreedte, deze foutmarge en deze fallback.

Agents verhogen waarde, maar ook foutkosten

De verschuiving richting agentic tooling is een belangrijk signaal. Tools zoals een code-omgeving met remote-controlachtige mogelijkheden of een multi-agent computercoördinator wijzen op dezelfde richting: AI krijgt niet alleen een antwoordrol, maar ook een handelingsrol. Dat kan de waarde van AI vergroten, omdat software, documenten, spreadsheets of interne systemen niet alleen beschreven maar ook bediend kunnen worden. Tegelijk verandert daarmee het risicoprofiel.

Een chatbot die een fout advies geeft, is vervelend. Een agent die een fout bestand overschrijft, een verkeerde dataselectie maakt, een workflow start of een actie uitvoert zonder controle, kan veel duurder uitpakken. Daarom moet elke agent-roadmap beginnen met actierechten. Welke acties mag het systeem zelfstandig uitvoeren? Welke acties mogen alleen na menselijke goedkeuring? Welke acties zijn voorlopig verboden? En waar wordt precies gelogd wat de agent zag, besloot en deed?

Een praktisch kader is om agent-acties in drie zones te verdelen. De groene zone bevat acties met lage foutkosten, zoals concepten opstellen, data structureren of een voorstel klaarzetten. De oranje zone bevat acties die waardevol zijn maar goedkeuring vragen, zoals wijzigingen in een CRM, publicatievoorstellen of aanpassingen aan code. De rode zone bevat acties die je pas toestaat na uitgebreide tests, rechtenbeheer en monitoring, zoals financiële handelingen, productie-deployments of definitieve klantcommunicatie.

Agentic workflows zijn dus niet productierijp omdat ze indrukwekkend lijken. Ze worden productierijp wanneer de taak klein genoeg is, de output meetbaar is, de rechten begrensd zijn en de gevolgen van fouten acceptabel zijn. Begin daarom niet met de ambitie ‘we bouwen agents’, maar met de vraag: welke specifieke taak heeft genoeg volume, genoeg controlepunten en genoeg waarde om een agent-experiment te verdienen?

Compute en chips horen in dezelfde roadmap als features

AI-roadmaps worden vaak geschreven als featureplannen: betere zoekfunctie, snellere support, automatische rapportage, slimmere copilots. Maar zodra workflows afhankelijk worden van grotere modellen, langere contexten, meerdere agentstappen of intensieve evaluaties, hoort compute bij dezelfde planning. Signalen rond grote chipdeals, gespecialiseerde transformerchips en nieuwe hardwareplanning zijn geen opdracht aan elk team om zelf hardwarestrategie te maken. Ze herinneren wel aan iets praktisch: AI-features draaien op schaarse, prijzige en leveranciergebonden infrastructuur.

Voor productteams betekent dit dat architectuurkeuzes niet neutraal zijn. Een realtime agent met meerdere modelcalls vraagt iets anders dan een nachtelijke batchanalyse. Een workflow die multimodale input verwerkt, kan andere kosten en latency hebben dan tekstclassificatie. Een product dat zwaar leunt op één modelprovider kan sneller bouwen, maar moet bewust omgaan met voorwaarden, prijswijzigingen en productrichting. Dat is geen reden om alle lock-in te vermijden; het is wel een reden om lock-in bewust te kiezen.

Maak compute daarom concreet in je roadmap. Noteer per use-case of de taak realtime moet zijn of batch kan draaien. Noteer hoeveel modelstappen nodig zijn, welke stappen met een kleiner model kunnen, waar caching mogelijk is en welke output door mensen wordt gecontroleerd. Bepaal ook wat er gebeurt als een gekozen model tijdelijk niet beschikbaar is of als kosten hoger uitvallen dan verwacht. Een fallbackmodel, versimpelde workflow of wachtrijmechanisme kan dan belangrijker zijn dan de nieuwste modelnaam.

Een 90-dagen besliskader voor AI-teams

De komende 90 dagen hoeven AI-teams niet elke modelupdate om te zetten in een proof-of-concept. Beter is een drie-sporenaanpak. Spoor één is modelevaluatie: kies twee of drie workloads en test modellen op eigen data, met vaste criteria voor kwaliteit, latency, kosten en fouttypes. Spoor twee is agentbegrenzing: definieer voor één workflow welke acties automatisch mogen, welke goedkeuring vragen en welke nog niet zijn toegestaan. Spoor drie is infrastructuurafhankelijkheid: breng modelprovider, toolprovider, dataflow, deployment, logging en contractuele afhankelijkheden in kaart.

Gebruik daarbij een vervangbaarheidsplan. Schrijf per use-case op welk onderdeel je later redelijk kunt vervangen en welk onderdeel diep in je product zit. Een promptlaag is vaak makkelijker aan te passen dan een volledig herschreven proces. Een losse evaluatieservice is makkelijker te vervangen dan een workflow waarvan alle businessregels in één agentprompt zitten. Een contract met duidelijke dataverwerking, supportafspraken en exportmogelijkheden maakt overstappen minder pijnlijk dan een ondoorzichtige toolketen.

Het doel is niet om onzekerheid weg te managen. AI blijft bewegen. Het doel is om onzekerheid te kanaliseren. Als je weet welke afhankelijkheden je accepteert, welke je test en welke je voorlopig vermijdt, wordt de roadmap rustiger. Dan bouw je niet rond het hardste persbericht, maar rond de onderdelen die je kunt meten, begrenzen en beheersen.

Pascal’s praktische conclusie

Voor Funnel Adviseur zou ik een AI-roadmap niet presenteren als een keuze tussen leveranciers, maar als een beslisdocument voor afhankelijkheden. Welke taak verdient AI? Welke output is goed genoeg? Welke agent-acties zijn veilig genoeg? Welke infrastructuurkosten zijn acceptabel? Welke onderdelen kunnen we vervangen zonder het product opnieuw te bouwen? Dat zijn de vragen die een AI-team helpen om van nieuws naar uitvoering te gaan.

De teams die hier volwassen in worden, hoeven niet elke update te negeren. Ze hoeven ook niet overal achteraan. Ze gebruiken modelnieuws als input, agentontwikkeling als experimentgebied en compute-signalen als risicofactor. Zo ontstaat geen spectaculaire, maar wel houdbare AI-strategie: klein genoeg om te testen, stevig genoeg om te schalen en eerlijk genoeg over de afhankelijkheden die erbij horen.