Wat een AI-implementatiepartner Moet Opleveren: De Vijf Documenten om naar te Vragen

Wat een AI-implementatiepartner moet opleveren: vijf documenten, geen presentatie

De klantenlijst van een leverancier kun je niet inspecteren, want de goede noemen hun klanten niet en de leveranciers die dat wel doen, laten je logo’s zien, geen werk. Een pod engineers kun je niet inspecteren. Een document wel. Dit artikel noemt de vijf documenten die een AI-implementatiepartner bij elk traject moet opleveren, in de volgorde waarin ze ontstaan, met wie in je organisatie elk document leest en wat het die persoon laat beslissen. Kan een partner deze niet benoemen, of levert hij in plaats daarvan een statuspresentatie, dan heb je vóór ondertekening iets nuttigs geleerd.

De lijst is niet willekeurig. Het is de set documenten die de vijf vragen beantwoordt die een koper werkelijk heeft: weet de partner hoe ons werk echt loopt, hoeveel hiervan is echt AI, hoe weten we of het nog klopt, kunnen we een beslissing van het systeem verdedigen, en betekent dit dat we onze software moeten vervangen. Een statuspresentatie beantwoordt er geen. De vijf documenten beantwoorden er elk één.

1. Het Uitzonderingenregister: weet de partner hoe het werk echt loopt?

Het Uitzonderingenregister is een schriftelijk overzicht van elke echte afwijking van het gedocumenteerde proces: wat die veroorzaakt, hoe vaak die voorkomt en wie die vandaag opvangt. Het is het eerste document omdat al het andere ervan afhangt, en het is het document dat niet uit een workshop of vragenlijst kan komen. Het ontstaat door lang genoeg naast degene te zitten die de workflow uitvoert om de veertig e-mailformaten te zien, de klant die belt, de leveranciersfactuur die verwijst naar een inkooporder die niet bestaat, en de goedkeuring die op vrijdag naar een andere manager gaat.

Wie het leest: de COO of operationeel directeur. Wat het die persoon laat beslissen: of het proces het automatiseren überhaupt waard is, en welke uitzonderingen de automatisering moet overleven. Een uitzondering die niemand heeft vastgelegd, wordt een stap waarvan stilzwijgend wordt verwacht dat het model hem afhandelt, en zo sterft een pilot die de demo doorstond in maand twee. Over het onderliggende probleem schreven we in waarom het gedocumenteerde proces nooit het echte proces is.

De toets voor een partner: vraag hoe lang ze met de mensen die het werk doen doorbrengen voordat ze een scope schrijven. Een dag is te weinig. Een kwartaal is factureren, geen discovery. Vijf dagen op één workflow is de bandbreedte waarin het register wordt geschreven zonder dat de factuur het doel wordt.

2. De AI-grensmap: hoeveel hiervan is echt AI?

De grensmap loopt de workflow stap voor stap door en classificeert elke stap als deterministische code, modeloordeel of een beslissing die bij een mens blijft. Het kerngetal is de determinismeratio: het aandeel stappen dat gewone software is. Die ligt meestal hoger dan de presentatie van de leverancier aannam. In de orderverwerking van een Europese fabrikant die SUPALABS in kaart bracht, hadden drie van de elf stappen echt een model nodig; de andere acht waren parsing, opzoekingen, validatie en routering (SUPALABS-projectdata, 2024–2026).

Wie het leest: de CIO, en de budgethouder. Wat het die persoon laat beslissen: wat het systeem gaat kosten om te draaien, hoe snel het wordt, en wat je aan een auditor kunt laten zien als regel in plaats van het als steekproef te moeten verdedigen. Elke stap die buiten het model blijft, is goedkoper, sneller en reproduceerbaar. Een partner die deze map niet kan maken, verkoopt een platform dat geprijsd is alsof elke stap van de moeilijke soort is, of heeft niet goed genoeg gekeken om het te weten.

De toets voor een partner: vraag welk aandeel van het voorgestelde systeem deterministisch is. Een partner die antwoordt “het is allemaal AI”, beschrijft zijn demo. Een partner die antwoordt met een getal en een lijst, beschrijft jouw proces. Die van ons kun je bekijken voordat je met ons praat: een geanonimiseerd Uitzonderingenregister en een AI-grensmap uit een echt traject.

3. De Evaluatiesuite: hoe weten we of het nog klopt?

De Evaluatiesuite is een golden dataset op basis van je eigen historische cases, de orders die je team correct verwerkte, de facturen die klopten, de concepten die een senior professional zou hebben geaccepteerd, stap voor stap gescoord, met slagingspercentages per stap en een maandelijks nauwkeurigheidsrapport dat na de livegang ertegen draait. Hij hoort als aparte post op de offerte te staan en nooit in de bouw te zijn weggewerkt, want een gebundelde evaluatie is het eerste wat sneuvelt wanneer de bouw uitloopt.

Wie het leest: het hoofd transformatie, en de board pack. Wat het die persoon laat beslissen: of het systeem zes maanden na het vertrek van de partner nog klopt, en of een taak meer bevoegdheid heeft verdiend. De suite maakt ook de bevoegdheidsniveaus echt: een taak gaat pas van concepten maken naar zelfstandig handelen wanneer het slagingspercentage dat jij hebt vastgelegd op echte cases wordt gehaald, en gaat weer omlaag zodra het maandrapport een regressie laat zien. Zonder de suite is “human in the loop” een slogan; met de suite is het een drempel.

Dit wordt elk jaar belangrijker, omdat het vertrouwen in modeloutput daalt terwijl het gebruik stijgt. De Stack Overflow Developer Survey van 2025 vond dat 84% van de developers AI-tools gebruikt of van plan is te gebruiken, terwijl 46% de nauwkeurigheid ervan actief wantrouwt en slechts 33% erop vertrouwt. Dat zijn de mensen die de systemen bouwen. Een COO die gevraagd wordt er één in productie te vertrouwen, heeft recht op een getal, niet op een verzekering.

De toets voor een partner: vraag de evaluatiepost op de offerte te zien. Staat die er niet, vraag dan waarom. Is die gebundeld, vraag dan wat ermee gebeurt als de bouw uitloopt.

4. Het Beslissingslogboek: kunnen we een beslissing van het systeem verdedigen?

Het Beslissingslogboek legt elke geautomatiseerde actie vast, met de input, de zekerheidsscore en wie die heeft goedgekeurd, in een overzicht dat een compliance officer, een financial controller of het due-diligenceteam van een koper kan openen zonder een engineer te vragen. Het bouwen ervan is basiswerk. Het onderscheid zit volledig in de vraag of het je vóór ondertekening wordt getoond, in een vorm die iemand zonder technische achtergrond kan lezen.

Wie het leest: compliance, finance, en iedereen die ooit een beslissing moet uitleggen aan een toezichthouder, een auditor of een koper. Wat het die persoon laat beslissen: of elke afzonderlijke beslissing van het systeem kan worden gereconstrueerd en verdedigd. Voor een bedrijf dat aangifte doet bij een belastingdienst, rapporteert aan een arbeidsinspectie of onder een financiële toezichthouder valt, is dat het verschil tussen een geautomatiseerd proces en een onverklaarbaar proces.

De toets voor een partner: vraag om een geanonimiseerd Beslissingslogboek uit een eerder traject. Een partner die er geen kan laten zien, bouwt er geen of denkt niet dat je ernaar vraagt.

5. De ERP-toezegging: betekent dit dat we onze software moeten vervangen?

Het vijfde document is het kortste en het vaakst ontbrekende: een schriftelijke toezegging, aan het begin gedaan, dat de partner bouwt bovenop de systemen die je al gebruikt en niet zal voorstellen ze te vervangen. Geen voorkeur. Een clausule. Een replatformingprogramma is het grootste carrièrerisico dat een operations- of IT-leider kan nemen, en het is bijna nooit wat het probleem werkelijk vraagt; de workflow is traag door de uitzonderingen en de overdrachten, niet door de database eronder.

Wie het leest: de CIO, en degene die de migratie zou moeten dragen. Wat het die persoon laat beslissen: dat dit traject geen vermomde replatforming is. De toezegging heeft een tweede helft die het waard is om in dezelfde clausule te vragen: wanneer het traject eindigt, blijft het systeem. Het draait in jouw accounts, op jouw systemen, vanaf de eerste week gedocumenteerd voor je team, en het stoppen van de dienst stopt de workflow niet.

De toets voor een partner: vraag of ze “geen vervanging, geen migratie” in de scope willen zetten. Een partner die daarover draait, houdt de migratie achter de hand.

Waarom de volgorde ertoe doet

Partners die een deel van deze documenten maken, doen dat vaak in de verkeerde volgorde, en juist in de volgorde zit de waarde. De grensmap kan pas worden getekend als de uitzonderingen zijn opgeschreven, omdat een niet-vastgelegde uitzondering een stap wordt waarvan stilzwijgend wordt verwacht dat het model hem afhandelt. De Evaluatiesuite kan pas worden gebouwd als de grensmap zegt welke stappen een oordeel bevatten dat je kunt evalueren; een opzoeking scoren heeft geen zin. Het Beslissingslogboek betekent pas iets als de suite definieert hoe een correcte beslissing eruitziet. En de toezegging komt nog vóór al het andere, omdat alles is ontworpen rond systemen die je houdt. Sla een stap over en de volgende is een gok. Dit is de volgorde die volledig wordt beschreven op de methodepagina van SUPALABS, en daarom komen uit elk traject dezelfde vijf documenten, ongeacht de sector. Dat maakt ze ook vergelijkbaar als je voor meer dan één business unit inkoopt of, zoals we voor sponsors beschrijven op de private-equitypagina, voor meer dan één portfoliobedrijf.

Wat dit vervangt

De vijf documenten vervangen drie dingen die kopers meestal in plaats daarvan krijgen aangeboden. Ze vervangen de logomuur, omdat een document over jouw proces meer zegt dan een lijst bedrijven waarvan je de processen niet kunt zien. Ze vervangen de testimonial, omdat een maandelijks nauwkeurigheidsrapport een testimonial is die het systeem over zichzelf schrijft. En ze vervangen de methodiekpresentatie, omdat een presentatie voor elke klant hetzelfde is en deze documenten niet. Biedt een partner je die eerste drie aan en kan hij de vijf niet leveren, dan is dat gat het antwoord.

Bronnen & referenties