AI implementatie: waarom data en processen belangrijker zijn dan de demo

Luister een podcast over wat we bespreken:

Een AI implementatie kan indrukwekkend beginnen. Een chatbot beantwoordt een vraag, een agent haalt informatie uit een document en een model voorspelt iets wat eerder uren handwerk kostte. Maar een demo toont vooral wat mogelijk is onder gecontroleerde omstandigheden. De echte test begint wanneer de oplossing met actuele bedrijfsdata, verschillende gebruikers en uitzonderingen moet werken.

Dat verschil wordt zichtbaar in recent onderzoek van Dun & Bradstreet. 75 procent van 10.000 bedrijven rapporteert al enige vorm van AI ROI, terwijl slechts 6 procent zegt dat de data volledig klaar is om AI op schaal te ondersteunen. De interessante conclusie is niet dat AI weinig oplevert. Het is dat eerste waarde en duurzame schaalbaarheid twee verschillende problemen zijn.

Daarom begint een volwassen implementatie niet met de vraag welk model het beste is. Eerst moeten de beschikbare bronnen, toegangsrechten en processen worden begrepen. Daarna volgen een beperkte use case, een vaste evaluatieset, beveiliging en duidelijke KPI's. Pas dan ontstaat de overgang van prototype naar productie.

AI implementatie levert al ROI op, maar de demo verbergt de echte schaalproblemen

Een prototype hoeft niet meteen alle bedrijfsdata te begrijpen. Voor een eerste test kan een beperkte set documenten, een afgebakende gebruikersgroep en menselijke controle voldoende zijn. Daarmee wordt onderzocht of een model een concreet probleem kan oplossen. De omstandigheden zijn overzichtelijk en fouten kunnen direct worden gecorrigeerd.

Productie stelt andere eisen. De broninformatie verandert, gebruikers hebben verschillende rechten en de invoer wijkt af van de voorbeelden uit de demo. Een chatbot die met tien zorgvuldig gekozen vragen goed werkt, is nog geen betrouwbare bedrijfsapplicatie. In de praktijk moet de oplossing ook omgaan met ontbrekende gegevens, tegenstrijdige documenten, verouderde informatie en vragen buiten de afgesproken scope.

Daar zit de kloof tussen ROI en schaal. Een prototype kan al tijd besparen of aantonen dat een proces kansrijk is. Dat betekent nog niet dat de oplossing beheersbaar blijft wanneer honderden medewerkers of klanten haar dagelijks gebruiken. De kosten per verzoek, responstijd, foutafhandeling en controleerbaarheid worden dan onderdeel van het resultaat.

De overgang van demo naar productie vraagt daarom om meer dan een betere prompt. Bij een RAG oplossing moeten documenten bijvoorbeeld niet alleen semantisch doorzoekbaar zijn. Ook versie, datum, bron en toegangsrecht moeten worden meegenomen. Hybride zoektechnieken kunnen helpen om zowel betekenis als exacte termen te vinden. Bij actuele informatie kan een koppeling met een systeem of live bron nodig zijn.

Metbyte kiest daarom voor snel leren zonder de vervolgstap uit het oog te verliezen. In een AI prototype in drie weken wordt een use case in drie sprints onderzocht. Het doel is niet alleen een overtuigende demo, maar ook zicht op de pijnpunten en wat nodig is om van een MVP naar een schaalbare toepassing te gaan. Dat is een andere houding dan een prototype presenteren als eindproduct.

Begin met een data en rechteninventaris, niet met een grote migratie

De eerste vraag bij data readiness is niet hoeveel data een organisatie bezit. De betere vraag is welke bronnen nodig zijn voor één concreet proces, wie ze beheert en onder welke voorwaarden ze gebruikt mogen worden. Een inventarisatie maakt zichtbaar waar de relevante informatie staat: in een DMS, CRM, ERP, gedeelde map, mailbox of losse spreadsheet.

Per bron zijn enkele eigenschappen bepalend. De eigenaar moet bekend zijn, net als de actualiteit, structuur, gevoeligheid en herkomst. Ook moet vaststaan of de organisatie het recht heeft om de gegevens aan een AI toepassing of externe modelprovider beschikbaar te stellen. Dat laatste wordt gemakkelijk vergeten wanneer documenten intern al breed worden gedeeld.

Toegangsrechten zijn geen technische bijzaak. Een AI systeem dat informatie kan vinden, mag die informatie niet automatisch aan iedere gebruiker tonen. De rechten van de bron moeten worden doorgegeven aan de zoeklaag en de applicatie. Anders kan een medewerker via een ogenschijnlijk onschuldige vraag gevoelige personeelsinformatie, klantgegevens of interne besluitvorming terugvinden.

Een volledige herinrichting van het dataplatform is voor een eerste use case meestal niet nodig. Een gecontroleerde bronset met duidelijke rechten kan genoeg zijn om de haalbaarheid te testen. Dat voorkomt dat maanden worden besteed aan een brede migratie voordat duidelijk is welk proces werkelijk waarde oplevert. Wel moeten de beperkingen van die beperkte bronset expliciet worden vastgelegd.

Bij een documentgebaseerde chatbot gaat het vervolgens om meer dan documenten in een vector database plaatsen. Segmentatie, metadata, versies en bronverwijzingen bepalen mede of antwoorden controleerbaar zijn. In de uitleg over een RAG chatbot wordt beschreven waarom documentkennis soms moet worden gecombineerd met CRM data of actuele informatie uit een koppeling. De bron bepaalt uiteindelijk de grens van wat de AI betrouwbaar kan weten.

De beste eerste AI use case is één proces met een meetbare uitkomst

“AI inzetten in de organisatie” is geen use case. Het is een ambitie. Een bruikbaar startpunt is één proces met een duidelijk begin, einde, eigenaar en resultaat. Dat kan bijvoorbeeld het beantwoorden van inhoudelijke klantvragen zijn, het voorbereiden van een rapport of het verzamelen van informatie uit meerdere systemen.

De keuze voor het proces bepaalt vaak meer dan de keuze tussen modellen. Een taak met veel herhaling, duidelijke input en een controleerbare uitkomst is eenvoudiger te testen dan een brede opdracht als “maak de klantenservice slimmer”. Ook variatie moet worden meegenomen. Een standaardaanvraag, een spoedgeval en een juridisch complexe uitzondering horen niet zonder meer in dezelfde meetlat.

Een praktische procesanalyse beschrijft per stap de invoer, handeling, verantwoordelijke, gebruikte applicatie, wachttijd en mogelijke uitkomst. Daarmee worden de plekken zichtbaar waar informatie verdwijnt of werk terugkomt. Soms blijkt dat niet AI, maar een ontbrekende regel of slecht ingerichte overdracht de grootste oorzaak van vertraging is.

Een goede nulmeting bevat bijvoorbeeld de huidige doorlooptijd, het aantal handmatige handelingen, herstelwerk, escalaties en kosten per geval. Daarna kan worden vastgesteld wat de AI wel en niet mag doen. Bij een laag risico kan de oplossing een conceptantwoord maken. Bij een gevoelig proces blijft menselijke goedkeuring nodig. Een agent die zelfstandig acties uitvoert, vraagt om strengere grenzen dan een zoekinterface die alleen bronnen toont.

De technische vorm volgt uit het proces. Generatieve AI is geschikt voor taal, samenvatting en interactie. Traditionele machine learning past beter bij voorspellingen op gestructureerde historische data. Rule based logica blijft nuttig voor harde voorwaarden. RAG is relevant wanneer antwoorden moeten steunen op bedrijfsdocumenten. Een agent kan taken opdelen en tools aanroepen, maar verhoogt ook de complexiteit en het risico.

Een voorbeeld is de maatwerk chatbot voor VOO. Daar werd de kennisbasis iteratief uitgebreid en werden modellen en instructies getest. Het resultaat was dat meer dan 95 procent van de vragen correct kon worden beantwoord. Belangrijker nog: gesprekken konden worden bekeken, de AI kon worden bijgestuurd en gebruikte bronnen konden worden gecontroleerd. Dat maakt kwaliteit onderdeel van het proces, niet alleen van de presentatie.

Een evaluatieset maakt “het werkt goed” toetsbaar voordat gebruikers gaan klagen

Een demo selecteert vaak de beste voorbeelden. Een evaluatieset doet het tegenovergestelde. Die bevat representatieve vragen, lastige uitzonderingen, ontbrekende informatie en situaties waarin de AI juist moet weigeren of escaleren. Zonder zo'n vaste set blijft “het werkt goed” een indruk die bij iedere wijziging opnieuw kan verschuiven.

Voor een AI toepassing met bedrijfskennis kunnen de testgevallen worden beoordeeld op meerdere punten: is het antwoord feitelijk juist, komt het uit de juiste bron, is de bron actueel en worden toegangsrechten gerespecteerd? Bij een agent komen daar correcte toolkeuze, juiste parameters en veilige afronding bij. Een mens kan de eerste beoordelingsset samenstellen, maar de criteria moeten daarna herhaalbaar blijven.

De technische score is niet hetzelfde als bedrijfswaarde. Een model kan inhoudelijk goed antwoorden en toch weinig opleveren wanneer medewerkers ieder antwoord moeten herschrijven. Daarom horen ook proces-KPI's bij de evaluatie: doorlooptijd, herstelwerk, aantal escalaties, beantwoorde vragen, kosten per interactie en klantuitkomst.

Een bruikbare evaluatieset bevat bij voorkeur een vaste nulmeting en een afgesproken ondergrens. Nieuwe prompts, modellen of databronnen worden niet alleen getest op enkele recente voorbeelden, maar tegen dezelfde verzameling. Zo wordt zichtbaar of een verbetering op het ene type vraag nieuwe fouten op een ander type vraag veroorzaakt.

Monitoring begint na livegang opnieuw. Logboeken moeten inzicht geven in verzoeken, gebruikte bronnen, responstijd, tokens, kosten en foutmeldingen, zonder onnodig gevoelige inhoud vast te leggen. Bij piekbelasting zijn rate limits, retries en een fallback nodig. Een lage betrouwbaarheid of onduidelijke bron moet kunnen leiden tot menselijke behandeling.

Ook de kosten horen in de evaluatie. Iedere modelaanroep heeft gevolgen voor het budget en lange contexten kunnen de rekening verhogen. Een AI engineering aanpak die let op effectiviteit en kosten behandelt tokengebruik daarom niet als een detail voor later. Een oplossing die inhoudelijk goed werkt maar financieel onvoorspelbaar is, is nog niet productierijp.

Productie vraagt om toegangscontrole, monitoring en een eigenaar na de demo

De laatste stap is organisatorischer dan veel teams verwachten. Een prototype heeft vaak een maker die precies weet hoe het werkt, welke beperkingen gelden en waar fouten kunnen ontstaan. In productie moet een andere medewerker de oplossing kunnen beheren, controleren en terugzetten wanneer dat nodig is.

Daarvoor zijn duidelijke verantwoordelijkheden nodig. Wie beheert de brondata? Wie beoordeelt een fout antwoord? Wie beslist over wijzigingen aan prompts, modellen of koppelingen? Wie krijgt een melding bij oplopende kosten of storingen? Zonder eigenaar wordt AI al snel een applicatie die wel wordt gebruikt, maar niet structureel wordt verbeterd.

Security begint bij de datastroom. Welke gegevens gaan naar de modelprovider, waar worden ze verwerkt en hoe lang blijven logs bewaard? Zijn persoonsgegevens nodig, en is de verwerking toegestaan? Zijn gebruikers geauthenticeerd? Kunnen zij alleen documenten raadplegen waarvoor zij al rechten hebben? Deze vragen raken aan AVG, privacy, informatiebeveiliging en de verplichtingen die uit de AI Act kunnen volgen.

Guardrails moeten passen bij het risico. Inputvalidatie kan ongewenste opdrachten of gevoelige gegevens tegenhouden. Outputvalidatie kan verplichte velden en toegestane acties controleren. Een human in the loop kan nodig zijn bij financiële, juridische of personele gevolgen. Bij een agent die meerdere systemen gebruikt, moet bovendien worden vastgelegd welke acties zelfstandig mogen worden uitgevoerd.

Integratie is de plek waar de demo vaak tegen de werkelijkheid botst. Een losse chatbot is iets anders dan een toepassing die CRM, ERP, DMS, datawarehouse of e-mail gebruikt. API's kunnen uitvallen, gegevens kunnen verouderd zijn en systemen kunnen elkaar tegenspreken. Een productieversie heeft daarom foutafhandeling, logging, toegangsbeheer, limieten en een terugvalscenario nodig.

Bij complexere processen kan orchestration helpen. Een centrale agent deelt werk op, gespecialiseerde onderdelen voeren taken uit en de resultaten worden samengevoegd. Dat patroon kan overzicht geven, maar maakt monitoring en aansprakelijkheid ook belangrijker. In de case van de AI gedreven website audit zijn onder meer fallbacks, retries, guardrails en kostenlimieten onderdeel van de oplossing. Zulke voorzieningen zijn minder zichtbaar dan de uiteindelijke output, maar bepalen of een toepassing blijft werken wanneer de omstandigheden veranderen.

De AI honeymoon is voorbij. Niet omdat modellen geen waarde meer hebben, maar omdat organisaties steeds vaker moeten aantonen wat een toepassing kost, oplevert en veroorzaakt. De AI honeymoon is over beschrijft die verschuiving naar een nuchterder ROI gesprek. De volgende stap is daarom niet automatisch een groter model. Het is een kleinere, beter begrensde productieomgeving waarin data, proces, rechten en verantwoordelijkheid samen kloppen.