Eerlijk gezegd vraag ik me regelmatig af hoeveel mensen deze modellen ook echt zelf testen. Veel berichten zijn vooral gebaseerd op benchmarks of cijfers van de makers. Als CTO van een AI-portaal heb ik gelukkig de ruimte om nieuwe modellen zelf uit te proberen. Zo lieten we bij Localign verschillende modellen de Nederlandse havo-eindexamens maken, met dezelfde examens en officiële antwoordmodellen. Dat leverde duidelijke verschillen op tussen vakken, modellen en kosten.
Sommige modellen zijn in de basis aantoonbaar beter. Ze redeneren consistenter, volgen instructies nauwkeuriger of verwerken meer informatie. Toch wordt hun prestatie in een AI-portaal minstens zoveel bepaald door de context die ze ontvangen. Welke informatie krijgt het model? Welke instructies zijn meegegeven? Welke hulpmiddelen kan het gebruiken?
Een goed model is daarom nog geen goede AI-assistent.
Een AI-interface is veel meer dan een model
Dat wordt duidelijk wanneer je een model rechtstreeks via een API gebruikt. Je stuurt een vraag en ontvangt een antwoord, maar krijgt niet automatisch dezelfde ervaring als binnen de ChatGPT of Claude interface. Rond zulke producten zit een complete agentic laag. Die bepaalt hoeveel context wordt meegestuurd, of er op internet moet worden gezocht, welke documenten relevant zijn, welke tools beschikbaar zijn en welk model het beste bij de opdracht past. Ook kan deze laag controleren welke gegevens gebruikt mogen worden en welke acties aanvullende toestemming vereisen.
Twee AI-portalen kunnen daardoor hetzelfde onderliggende model gebruiken en toch heel anders presteren. Het verschil zit niet alleen in het model, maar vooral in de manier waarop het wordt aangestuurd. Een API-koppeling met een taalmodel is tegenwoordig relatief snel gebouwd. Een AI-portaal ontwikkelen dat begrijpt wat iemand werkelijk probeert te bereiken, de juiste informatie verzamelt en daar betrouwbaar naar handelt, is veel ingewikkelder. Daarvoor is een agentic laag nodig tussen de gebruiker, modellen, informatie en mogelijke acties.
Van één vraag naar meerdere acties
Neem een opdracht die op het eerste gezicht eenvoudig lijkt:
“Vat de belangrijkste ontwikkelingen rond project X samen en schrijf een conceptmail aan het team.”
Een eenvoudige chatbot stuurt deze opdracht rechtstreeks naar een model. Een goede AI-assistent moet eerst bepalen over welk project het gaat, welke documenten en e-mails relevant zijn en of de gebruiker toegang heeft tot die informatie. Ook moet het AI-portaal vaststellen of de gegevens binnen de gekozen route mogen worden verwerkt en welke stappen achteraf inzichtelijk moeten zijn.
Pas wanneer voldoende context beschikbaar is, kan de assistent een betrouwbare samenvatting en conceptmail opstellen. Eén vraag leidt zo tot meerdere acties: interpreteren, zoeken, ophalen, controleren en schrijven. Sommige stappen zijn afhankelijk van eerdere resultaten, terwijl andere gelijktijdig kunnen worden uitgevoerd.
Het model blijft belangrijk, maar is binnen zo’n proces slechts één onderdeel van een bredere architectuur. De agentic laag bepaalt welke stappen nodig zijn, welke informatie het model krijgt en wanneer er genoeg bekend is om te antwoorden.
Bij Localign bouwen we aan precies die laag. Een vraag wordt niet standaard direct naar één model gestuurd. Het AI-portaal bepaalt welke modellen, bronnen, instructies, controles en acties nodig zijn. Juist daar ontstaan voor mij als CTO de lastigste ontwerpkeuzes.
De dagelijkse afweging: snelheid, kosten en kwaliteit
Mijn grootste struggle is het voortdurend balanceren tussen responstijd, kosten en kwaliteit, binnen vaste randvoorwaarden voor privacy, veiligheid en verantwoording. De grote spelers hebben duidelijke verwachtingen gezet: gebruikers willen vrijwel direct zien dat een assistent aan het werk gaat en snel een bruikbaar resultaat ontvangen. Ook Localign moet aan die standaard voldoen. Een zorgvuldig systeem dat te lang stil blijft, voelt al snel alsof het niet werkt.
Snelheid is alleen niet simpelweg een kwestie van een sneller model kiezen. Voor een antwoord kan het AI-portaal eerst de vraag classificeren, instructies ophalen, bronnen raadplegen, rechten controleren, tools aanroepen en resultaten combineren. Iedere stap kost tijd en geld.
Een concreet voorbeeld is de manier waarop je een assistent instructies geeft. Je kunt één grote systeemprompt maken waarin staat hoe hij e-mails schrijft, grafieken maakt, presentaties structureert en documenten analyseert. Dan zijn alle instructies altijd beschikbaar.
Maar bij een eenvoudige vraag over een document zijn de regels voor een PowerPoint niet nodig. Toch moet het model ze iedere keer verwerken. Dat vergroot de prompt, verhoogt de kosten en kan de verwerking vertragen.
Je kunt dit oplossen met een router die eerst bepaalt welke vaardigheden nodig zijn. Alleen de relevante instructies worden vervolgens geladen. Dat houdt prompts kleiner en gerichter. Maar de router is zelf weer een extra beslisstap, met extra latency en kosten. Bovendien kan hij een vaardigheid missen die later toch nodig blijkt.
Dezelfde afweging ontstaat bij het raadplegen van bronnen. Je kunt eerst precies bepalen welke bronnen nodig zijn en ze daarna doorzoeken. Dat voorkomt verspilling, maar kost tijd. Je kunt ook meerdere waarschijnlijke richtingen parallel starten. Terwijl het systeem documenten doorzoekt, kan het bijvoorbeeld alvast e-mails ophalen.
Dat kan veel sneller zijn, maar je betaalt mogelijk voor acties waarvan later blijkt dat ze niet nodig waren. Je koopt als het ware snelheid door meerdere deuren tegelijk te openen voordat je weet achter welke deur de juiste informatie ligt.
Het systeem kan zelfs alvast beginnen met formuleren voordat alle resultaten binnen zijn. Wanneer de eerste informatie de vermoedelijke richting bevestigt, levert dat tijdwinst op. Wanneer latere informatie de conclusie verandert, moet een deel van het werk opnieuw worden uitgevoerd.
Vrijwel iedere optimalisatie verschuift het probleem. Kleinere prompts zijn goedkoper, maar bevatten mogelijk te weinig context. Parallel werken verlaagt de wachttijd, maar verhoogt de kans op onnodige acties. Eerst nauwkeurig bepalen wat nodig is voorkomt verspilling, maar voegt juist weer latency toe.
Niet alle latency moet daarbij worden weg geoptimaliseerd. Controles op autorisaties en persoonsgegevens, het vastleggen van gebruikte bronnen en het vragen van toestemming voor bepaalde acties kosten tijd, maar zijn noodzakelijke voorwaarden voor verantwoord gebruik.
Uiteindelijk blijft kwaliteit doorslaggevend. Een snelle en goedkope assistent is weinig waard wanneer hij de verkeerde bron gebruikt of te vroeg conclusies trekt. Andersom is een theoretisch perfect antwoord dat pas na een minuut verschijnt voor veel dagelijkse werkzaamheden evenmin bruikbaar.
Niet iedere vraag verdient dezelfde route
De oplossing is daarom niet om iedere vraag door dezelfde uitgebreide keten te sturen. Een verzoek om één zin te herschrijven moet vrijwel direct kunnen worden afgehandeld. Daarvoor zijn geen zoekacties, gespecialiseerde tools of uitgebreide controles nodig.
Een verzoek om meerdere vertrouwelijke documenten te vergelijken en daar een onderbouwd advies uit te halen, rechtvaardigt juist wel meer context, extra controles en een langere verwerkingstijd. Zodra een assistent ook acties uitvoert, zoals een mail versturen of gegevens wijzigen, komen daar bovendien autorisaties, toestemming en logging bij.
Bij Localign proberen we daarom per opdracht een passende route samen te stellen. Eenvoudige vragen moeten eenvoudig blijven. Complexe opdrachten mogen meer werk veroorzaken, maar alleen wanneer dat waarschijnlijk bijdraagt aan het resultaat.
Soms kan een klein en snel model bepalen welke route nodig is, waarna een krachtiger model de analyse uitvoert. Bij een andere vraag is die tussenstap overbodig. Sommige acties kunnen veilig parallel worden gestart, terwijl het bij andere opdrachten verstandiger is om eerst meer zekerheid te krijgen.
De ideale route staat dus niet vooraf vast. Het AI-portaal moet tijdens de uitvoering bepalen welke intelligentie, informatie en controles werkelijk nodig zijn. Daar zit voor mij de kern van een goede AI-assistent: niet alleen in wat een model kan, maar in de keuzes die de agentic laag maakt over context, tools en timing.
Kijk verder dan de naam van het model
Voor organisaties die een AI-portaal selecteren, blijft de vraag welk model wordt gebruikt relevant. Maar minstens zo belangrijk is hoe het portaal bepaalt welke informatie nodig is, welke tools beschikbaar zijn, hoe autorisaties worden gerespecteerd en wat er gebeurt als een model of databron niet beschikbaar is.
Ook moet het onderliggende model vervangbaar blijven. Nieuwe modellen zullen blijven verschijnen en het model dat vandaag bovenaan een benchmark staat, kan over enkele maanden alweer zijn ingehaald. Daarom bouwen we Localign modelonafhankelijk en Europees. Niet omdat ieder Europees model automatisch beter is, maar omdat organisaties controle moeten kunnen houden over de volledige keten: van infrastructuur en gegevensverwerking tot routing en acties.
De volgende fase van AI wordt niet alleen gewonnen door wie het slimste model ontwikkelt. Ze wordt gewonnen door wie modellen betrouwbaar weet te verbinden met de juiste informatie, bevoegdheden en dagelijkse werkzaamheden.
Een goed AI-model kan een overtuigend antwoord formuleren. Een goede AI-assistent begrijpt eerst wat er daadwerkelijk moet gebeuren.
Deze blogpost is een bijdrage van Localign. Localign is een Europees AI-platform waarmee organisaties verschillende AI-modellen veilig en compliant vanuit één omgeving kunnen gebruiken, met behoud van controle over hun data. Ga voor meer informatie naar www.localign.com of kom langs bij de stand van Localign op Data Expo.