Van AI-pilot naar geaccepteerd operationeel proces

Een werkende demo beantwoordt één vraag: kan dit de taak uitvoeren op een goede dag? Een sponsor heeft een andere vraag. Kan de operatie er ook op een slechte dag op rekenen, als de invoer fout is, de goedkeurder afwezig is en het volgende systeem de update afwijst?

Veel AI-initiatieven blijven steken tussen die twee vragen. De BCG-enquête uit 2026 onder meer dan 115 bedrijfsleiders en meer dan 75 leiders van technologische dienstverleners beschrijft dat de meeste ondernemingen nog gerichte pilots met AI-agents draaien, dat ongeveer een derde opschaalt en dat velen verwachten dat aanbieders helpen om prioritaire toepassingen te bouwen en operationeel te maken. Het gaat om een enquête naar intenties, uitgevoerd vanuit de aanbiederskant; ze zegt dus niets over een resultaat van Sembium. Wel beschrijft ze de kloof waar dit artikel over gaat.

Wat een pilot wel en niet is

Bij Sembium is een pilot geen product. Een pilot bewijst één lastig onderdeel binnen een gefinancierd operationeel transformatieprogramma. Dat programma bevat al de nulmeting, het herontworpen proces, de integratie, de uitrol en de meting. De pilot toetst of de moeilijkste stap uit dat ontwerp standhoudt.

De richtlijn van Microsoft voor AI-agents zegt iets vergelijkbaars: test de moeilijkste stappen, en pauzeer en heroverweeg als een pilot de afgesproken resultaten niet haalt. Dezelfde richtlijn stelt dat gestructureerde, voorspelbare taken mogelijk helemaal geen agent nodig hebben en dat gewone code voor vaste werkstromen vaak sneller, goedkoper en betrouwbaarder is. Dat is hier relevant, omdat een goede pilot vaak laat zien dat een deel van de stap bij deterministische regels hoort en niet bij AI.

Vijf poorten tussen demo en operatie

De poorten hieronder volgen de programmalogica die Sembium voorstelt. Elke poort heeft een artefact, een verantwoordelijke eigenaar en een beslissing waarop “nee” een mogelijk antwoord is. Ze beschrijven een methode en geen opgeleverd klantwerk.

Poort 1: Scope en nulmeting afgesproken

Voordat er iets wordt gebouwd, spreken sponsor en proceseigenaar af wat er wordt gemeten en wat succes is. Microsoft adviseert eerst basisdoelen vast te leggen, het aantal maatstaven klein te houden en ze te gebruiken als beslismomenten om door te gaan, bij te sturen of te stoppen.

Artefacten: definitie en steekproef van de nulmeting, definitie van in aanmerking komende gevallen, succes- en faaldrempels, toegestane data, toegestane acties.

Poort 2: Lastig geval bewezen

De test omvat de moeilijke gevallen: dubbelzinnige documenten, tegenstrijdige registraties, ontbrekend bewijs, ongebruikelijke klanten. Ook de gevallen waarin het systeem moet weigeren of escaleren horen erbij. Een resultaat dat alleen typische gevallen dekt, is geen bewijs voor productie.

Hier wordt de verdeling tussen regels, AI en mensen expliciet. Bekende controles en statuswijzigingen gaan naar regels. AI wordt ingezet waar interpretatie nodig is. Mensen blijven de ingrijpende beslissingen nemen.

Artefacten: testset en beoordelingskader, resultaten inclusief bekende fouten, de beslismatrix voor regels, AI en mensen, en de werkwijze voor menselijke review.

Poort 3: Beheersing geaccepteerd

IT, security en de proceseigenaar beoordelen waar het systeem bij mag en wat er gebeurt als het misgaat. De OWASP-lijst 2025 voor LLM-toepassingen noemt prompt injection (LLM01), onthulling van gevoelige informatie (LLM02) en excessive agency (LLM06) als risico’s. In een operatie is excessive agency het praktische risico: het systeem kan meer dan bedoeld, omdat niemand de grens heeft getrokken.

Het AI Risk Management Framework van NIST beschrijft functies die deze poort nodig heeft: gedocumenteerde processen voor menselijk toezicht (Map 3.5), gescheiden rollen voor samenwerking tussen mens en AI (Govern 3.2) en mechanismen met toegewezen verantwoordelijkheid om een systeem te vervangen, los te koppelen of uit te schakelen als het gedrag niet past bij het beoogde gebruik (Manage 2.4). Het is een vrijwillige richtlijn en geen certificering; wie het gebruikt, voldoet daarmee niet automatisch aan regelgeving.

Artefacten: rechtenkaart (minimale rechten), ontwerp voor goedkeuring en overrulen, regels voor logging en maskering, rollbackprocedure met eigenaar, incidentcontacten, kosten- en gebruikslimieten.

Poort 4: Geïntegreerd en geborgd

Het systeem is via ondersteunde koppelingen verbonden met de echte bronsystemen. Het schrijft alleen wat het mag schrijven en elke schrijfactie laat bewijs achter. Er zijn foutroutes voor het geval een volgend systeem niet beschikbaar is of een update afwijst. Monitoring waarschuwt de eigenaar als het gedrag afwijkt.

NIST koppelt monitoring na livegang, incidentafhandeling en wijzigingsbeheer in de functie Manage (Manage 4.1 en 4.3). Dat herinnert eraan dat dit in de release hoort en niet erna.

Artefacten: integratiecontract, ontwerp voor monitoring en alarmering, gedrag bij fouten en herhaalpogingen, draaiboek, releasebewijs, afgetekend door de betrokken eigenaren.

Poort 5: Geadopteerd en belegd

Een release die niemand gebruikt, is mislukt, hoe schoon de architectuur ook is. Deze poort toetst of gebruikers zijn getraind, of de eerste groep op de nieuwe manier werkt, of uitzonderingen een thuis hebben en of iemand de verbeterlijst beheert.

Artefacten: adoptieplan en scope van de eerste groep, trainingsmateriaal, ondersteuningsverantwoordelijkheden, datum voor evaluatie van resultaat en kosten, benoemde eigenaren voor beslissingen, incidenten en wijzigingen.

Een synthetisch voorbeeld (illustratief, geen klantresultaat)

Stel je een fictieve B2B-leverancier voor waarvan de customer-to-cash-keten vertraging oploopt door factuurdisputen. Het programma bestrijkt de hele route van order tot betaling. Het lastigste onderdeel is het classificeren van disputcorrespondentie en het voorstellen van een vervolgstap. Alles hieronder is verzonnen om te laten zien hoe de poorten werken.

• Poort 1: de nulmeting meet de ouderdom van disputen en herstelwerk op een steekproef van afgesloten zaken. De drempels worden vóór de bouw met finance afgesproken.
• Poort 2: de testset bevat bewust dubbelzinnige e-mails en disputen met ontbrekend leveringsbewijs. Het systeem moet die naar een mens sturen in plaats van te gokken.
• Poort 3: het systeem kan disputdossiers lezen en een voorstel opstellen. Het kan geen creditnota uitgeven en geen kredietstatus wijzigen. Dat blijft bij benoemde goedkeurders, en één benoemde persoon kan de classificatiestap uitschakelen.
• Poort 4: classificatieresultaten worden met een bewijsspoor in het disputdossier vastgelegd. Mislukt het boeken, dan gaat de zaak naar een handmatige wachtrij en krijgt de eigenaar een melding.
• Poort 5: één team incassomedewerkers gaat als eerste aan de slag. Hun feedback verandert het reviewscherm vóór de volgende groep.

Niets in dit voorbeeld impliceert een bepaalde besparing, doorlooptijd of nauwkeurigheid.

Waarom pilots vastlopen: vier patronen

Dit zijn werkhypothesen van Sembium vanuit de methode, geen gemeten statistieken.

1. De pilot hoort bij geen enkel deel van het proces. Hij staat naast de operatie en wordt gevoed met handmatig gekozen data. Niemand in het echte proces is verantwoordelijk voor de uitkomst, dus niemand adopteert hem.
2. Het moeilijke deel was nooit het moeilijke deel. De demo voerde de zichtbare taak uit, terwijl het dure werk zat in uitzonderingen, goedkeuringen en systeemupdates die de pilot oversloeg.
3. Beheersing komt als laatste. Security en proceseigenaren zien het ontwerp pas nadat de demo al verwachtingen heeft gewekt. Hun bezwaren komen dan over als tegenwerking.
4. Succes is nooit gedefinieerd. Zonder nulmeting en drempels kan elk resultaat twee kanten op worden uitgelegd en verwatert de beslissing.

Poort 1 en 3 zijn er vooral om respectievelijk patroon 4 en 3 te voorkomen. Poort 2 pakt patroon 2 aan en poort 5 patroon 1.

Wie beslist wat bij welke poort

De rollen zijn indicatief. In jouw organisatie kan één persoon meerdere rollen vervullen en kunnen sommige bij een leverancier liggen. Wat telt, is dat elke poort een benoemde eigenaar heeft die nee kan zeggen.

Rollback hoort bij de release

Teams behandelen rollback vaak als iets wat je pas uitwerkt als er iets kapotgaat. Goedkoper en veiliger is het om rollback als releasecriterium te behandelen. Voor elke actie die het systeem kan uitvoeren, moet het acceptatiedossier drie vragen beantwoorden. Wie kan het stoppen? Wat doet de operatie terwijl het gestopt is? Hoe wordt een foute actie teruggedraaid of gecompenseerd?

Zijn de antwoorden onduidelijk, dan zijn de rechten te breed of het proces eromheen nog niet af. De rechten beperken is vaak de juiste oplossing.

Wat een klein senior team hier wel en niet kan

Deze aanpak is bedoeld voor een programma onder leiding van de oprichter, met specialisten die per opdracht worden samengesteld. Dat helpt bij directe verantwoordelijkheid en minder overdrachten. Het neemt het werk niet weg. Poort 3 tot en met 5 vragen mensen aan klantzijde die beheersing kunnen goedkeuren, kunnen integreren met bestaande systemen en kunnen veranderen hoe teams werken. Specialisten voor integratie, security of verandering worden per opdracht vastgelegd voordat er leveringsbeloften worden gedaan, en hun beschikbaarheid hangt af van de scope.

Stoppen is een legitieme uitkomst

Een pilot die zijn criteria niet haalt, heeft toch iets opgeleverd: bewijs over waar proces, data of aanpak nog niet klaar is. Microsoft behandelt go- en no-go-beslissingen als onderdeel van het plan. Door de criteria eerst af te spreken, blijft de beslissing zakelijk.

Wat dit niet bewijst

• De vijf poorten en hun producten beschrijven de methode die Sembium gebruikt. In een programma wordt elke drempel afgezet tegen je eigen nulmeting en afgesproken met de mensen die tekenen.
• De drempels in het synthetische voorbeeld zijn illustratief. Het zijn geen aanbevolen waarden voor jouw operatie.
• De externe cijfers beschrijven ondervraagde bedrijven in het algemeen. Ze voorspellen niet of jouw pilot opschaalt.
• Wie alle poorten passeert, laat zien dat een proces volgens afgesproken criteria is geaccepteerd. Dat bewijst op zichzelf nog geen positieve netto businesscase; daarvoor zijn een nulmeting en een waardemodel over een vaste horizon nodig.

Wanneer dit past

Dit pad past bij een operatie met een terugkerend proces over teams of systemen heen, een eigenaar op directieniveau, bruikbare toegang tot data en beslissers, en een knelpunt dat $1M of meer waard is om op te lossen. Scope en investering hangen af van domein, systemen, beheersing en specialistische inzet. Heb je alleen een kleine losse automatisering nodig, of kan niemand verandering goedkeuren, dan is het volledige programma waarschijnlijk niet het juiste gereedschap.

Heb je een pilot die werkt maar nog niet in jouw operatie kan draaien? In een gesprek van 30 minuten zoeken we de poort die hem blokkeert. Je krijgt één praktische aanbeveling, geen volledige diagnose.

Plan een gesprek van 30 minuten over je knelpunt