AI-producten als leersysteem: waarom productie-infra belangrijker wordt dan je demo

Van AI-demo naar AI-product

Een AI-demo is vaak overtuigend omdat de context smal is. Je kiest een taak, schrijft een goede prompt, voegt een paar documenten toe en laat zien dat het model bruikbare output kan maken. Dat is waardevol, maar het is nog geen product. Een enterprise-AI-product moet blijven functioneren wanneer gebruikers andere vragen stellen, wanneer documenten veranderen, wanneer uitzonderingen opduiken en wanneer de organisatie scherpere kwaliteitseisen krijgt.

Daarom is de vraag niet alleen welk basismodel je kiest. De belangrijkere ontwerpvraag is welke leerlus je rond het product bouwt. Wat mag het systeem leren van gebruik? Welke signalen zijn betrouwbaar genoeg? Wie beslist of nieuwe data gebruikt mag worden? Welke evaluatie bepaalt of nieuw gedrag beter is? En wat gebeurt er als een update slechter uitpakt dan verwacht?

De visie van een ‘levend systeem’ klinkt aantrekkelijk, maar voor productieomgevingen moet je die visie nuchter maken. Een levend AI-product is niet een systeem dat ongecontroleerd zichzelf verbetert. Het is een product waarin leren wordt ontworpen, begrensd, gemeten en terug te draaien is.

Wat continual learning concreet kan betekenen

Continual learning is een breed begrip. In een praktische productcontext kun je het beter opsplitsen in vijf werkbare onderdelen: feedback verzamelen, data cureren, evalueren, trainen of finetunen, en gecontroleerd uitrollen. Elk onderdeel heeft eigen risico’s. Een duim omhoog van een gebruiker is bijvoorbeeld niet hetzelfde als inhoudelijke correctheid. Een workflowtrace kan nuttig zijn, maar bevat mogelijk informatie die niet geschikt is voor training. Een betere score op één testset betekent niet automatisch dat het product in alle workflows beter is geworden.

Voor AI-teams is vooral de scheiding tussen signalen en beslissingen belangrijk. Je kunt veel signalen verzamelen zonder die direct te gebruiken voor modelupdates. Denk aan afgekeurde antwoorden, handmatige correcties, documenten die vaak geraadpleegd worden, promptvarianten, latencyproblemen en escalaties naar een menselijke expert. Die signalen worden pas waardevol wanneer ze door een curatieproces gaan.

Curatie betekent dat iemand of een proces bepaalt welke voorbeelden representatief, veilig en leerzaam zijn. Bij enterprise-AI is dat zelden puur technisch. Juridische kaders, klantafspraken, dataclassificatie, domeinexpertise en productdoelen spelen mee. Een team dat continual learning serieus neemt, begint daarom niet met automatische training, maar met afspraken over welke informatie überhaupt in de leerloop mag komen.

De drie ontwerpkeuzes voor AI-teams

De eerste ontwerpkeuze is data. Een AI-product kan leren uit expliciete feedback, workflow traces, domeindocumenten, supporttickets, correcties door experts of resultaten van interne evaluaties. Niet elk datatype heeft dezelfde waarde. Workflow traces laten zien waar het product wordt gebruikt, maar niet altijd of het antwoord goed was. Expertcorrecties zijn vaak rijker, maar duurder om te verzamelen. Domeindocumenten zijn nuttig, maar kunnen verouderd of tegenstrijdig zijn.

De tweede ontwerpkeuze is evaluatie. Zonder private evals blijft modelverbetering een gevoel. Een private eval is een interne testset die aansluit op de eigen processen, taal, uitzonderingen en kwaliteitsnormen. Voor een juridisch AI-product kan dat gaan om bronverwijzing, nuance en risicoherkenning. Voor een sales-assistent kan dat gaan om volledigheid, tone of voice en correcte kwalificatie. Het punt is niet dat één eval alles vangt, maar dat updates langs dezelfde meetlat kunnen.

De derde ontwerpkeuze is infrastructuur. Zodra een product kan veranderen, heb je versiebeheer nodig. Welke modelversie draaide op welk moment? Welke prompttemplate was actief? Welke retrieval-index is gebruikt? Welke dataset zat in de training? Welke evalscore hoorde bij de release? Zonder die basis wordt debugging giswerk. Rollback hoort daarom niet achteraf bedacht te worden. Het is een voorwaarde voordat je updates sneller of vaker wilt uitvoeren.

Modelkeuze is niet het eindpunt

In AI-teams krijgt modelkeuze begrijpelijk veel aandacht. Een basismodel bepaalt mogelijkheden, kostenprofiel, snelheid en technische randvoorwaarden. Een model zoals NeMoTron 3 Super kan in een technische stack een relevante keuze zijn, maar de modelnaam alleen vertelt niet hoe betrouwbaar het uiteindelijke productgedrag wordt. Dat gedrag ontstaat uit de combinatie van model, context, data-curatie, evaluaties, prompts, tooling en governance.

Hetzelfde geldt voor termen als online learning en Self-Distillation Policy Optimization. Ze kunnen onderdeel zijn van een geavanceerde trainingsaanpak, maar ze vervangen geen productdiscipline. De praktische vraag blijft: welk probleem los je op, met welke data, tegen welke evaluatie, en met welke controle op regressie? Een techniek is pas productwaardig wanneer je weet hoe je verbetering meet en hoe je schade beperkt wanneer de techniek niet het gewenste effect heeft.

Voor Funnel Adviseur is dit precies het punt waarop AI-strategie en automatisering elkaar raken. Een werkende AI-oplossing gaat niet alleen over slimme output, maar over een bedrijfsproces dat herhaalbaar, controleerbaar en uitlegbaar blijft. Wie AI in een B2B-omgeving inzet, moet de leerlus daarom ontwerpen als onderdeel van de funnel, operatie en klantbelofte.

Een praktische checklist voor productie

Begin met één leerdoel per workflow. Bijvoorbeeld: minder handmatige correcties op offerteconcepten, betere classificatie van inkomende aanvragen of consistenter beantwoorden van productvragen. Zonder leerdoel wordt continual learning een verzamelbak. Met een leerdoel kun je bepalen welke feedback relevant is en welke evaluatie nodig is.

Leg daarna vast welke feedback betrouwbaar genoeg is. Een gebruiker die een antwoord accepteert, kan dat doen omdat het antwoord goed is, maar ook omdat er tijdsdruk is. Een expertcorrectie is vaak sterker, maar moet nog steeds worden geïnterpreteerd. Maak daarom categorieën: ruwe signalen, gecureerde voorbeelden, goedgekeurde trainingsdata en releasewaardige evaluaties.

Maak private evals voordat je updates automatiseert. Een evalset hoeft niet meteen groot te zijn om nuttig te zijn. Start met representatieve cases, randgevallen en voorbeelden waar het huidige product faalt. Voeg naast outputkwaliteit ook procescriteria toe, zoals brongebruik, format, escalatiegedrag en ongewenste aannames. Zo voorkom je dat een update alleen op oppervlakkige vloeiendheid wordt beoordeeld.

Plan rollback voordat je online learning overweegt. Dat betekent: versies loggen, releases klein houden, monitoring inrichten en een duidelijke eigenaar aanwijzen. Als niemand bevoegd is om een modelupdate terug te draaien, is de leerlus organisatorisch nog niet af. Productie-infra is dan geen technische luxe, maar de randvoorwaarde voor veilig leren.

De nuchtere conclusie

AI-producten worden niet beter omdat ze een indrukwekkende demo hebben gehad. Ze worden beter wanneer teams systematisch leren van gebruik, fouten, correcties en evaluaties. Dat vraagt minder magie en meer productdiscipline: databeleid, curatie, private evals, releaseprocessen, monitoring en rollback.

Voor teams die voorbij de prototypefase zijn, ligt de waarde niet in het najagen van elk nieuw model. De waarde ligt in een stack waarin modelkeuze, domeinkennis en productfeedback elkaar versterken zonder de controle te verliezen. Een enterprise-AI-product mag leren, maar alleen binnen grenzen die het team begrijpt en kan beheren.