AI-automatisering: welke taken je wel en niet aan software geeft

Wat is het verschil tussen RPA en AI-automatisering?

RPA volgt vaste stappen: open dit scherm, kopieer dat veld, plak het daar. Dat werkt zolang de invoer er elke keer hetzelfde uitziet. AI-automatisering kan omgaan met invoer die steeds anders is, zoals een e-mail in eigen woorden of een factuur in een onbekend formaat.

Daar staat iets tegenover: de uitkomst is niet elke keer gegarandeerd dezelfde. Een AI-automatisering heeft daarom een testset nodig die laat zien hoe vaak hij het goed doet, en een moment waarop een medewerker de twijfelgevallen ziet. Is je invoer wel elke keer hetzelfde, dan is een gewone regel of RPA goedkoper en voorspelbaarder.

Vier niveaus: wat de software zelf mag

Per taak kies ik één van vier niveaus. Die keuze bepaalt meer van het resultaat dan het model dat eronder draait. Een taak begint laag en gaat pas een niveau omhoog als de testset dat laat zien: de score moet een afgesproken drempel halen, zonder ernstige fouten in de meetperiode. Zakt de score later, dan gaat de taak een niveau terug.

0. Handmatig

Een medewerker doet het werk, de software kijkt mee en legt vast. Zo leer je hoe de taak echt loopt, met alle uitzonderingen, voordat je iets automatiseert.

1. Concept

De software maakt een concept en een medewerker keurt het goed voordat er iets naar buiten gaat. Een conceptantwoord op een klantvraag is het bekendste voorbeeld.

2. Binnen grenzen

De software handelt zelf af binnen vaste grenzen, en een medewerker controleert steekproeven. Wat buiten de grenzen valt, gaat naar een mens.

3. Zelfstandig

Alleen voor stappen die je kunt terugdraaien en waar een fout weinig schade doet. De mens bepaalt de regels, niet elke uitkomst.

Hoe ik het zelf gebruik

Ik draai mijn eigen bedrijf op hetzelfde model. Een paar voorbeelden, met het niveau waarop ze staan.

Leads beoordelen (1)

Software zoekt informatie over een bedrijf op en geeft een oordeel of het past. Er komt niets in mijn pipeline zonder dat ik het heb goedgekeurd.

LinkedIn-posts (1)

Een agent zet een concept klaar in een tabel. Online gaat het pas als ik het heb goedgekeurd; de agent kan die status zelf niet zetten.

Dagelijkse pipeline-update (2)

Loopt elke dag zelf, binnen vaste grenzen over wat hij mag aanpassen. Ik controleer steekproeven.

Bezoekersmelding op deze site (3)

Een bezoek vanaf een bedrijfsnetwerk komt als bedrijfsnaam in een Slack-kanaal, zonder dat iemand iets goedkeurt. Een fout kost niets en is direct te herstellen. Hoe dat werkt, staat op mijn privacypagina.

Nooit hoger dan 1

Prijzen, klantcontact en de beslissing om iets niet te bouwen. Daar kan software voorbereiden, maar beslis ik zelf.

Rekenvoorbeeld: wat levert het op?

Een fictief voorbeeld, om de som te laten zien. Een groothandel krijgt 400 bestellingen per week per e-mail. Een medewerker typt elke bestelling over in het ordersysteem, gemiddeld 6 minuten per stuk: 40 uur per week.

Na de bouw leest de software de mails en zet de orders klaar. Daar horen twee aparte metingen bij. De eerste: hoeveel mails zet de software zelf door? Stel 70%: dan gaan er 280 automatisch door en 120 als twijfelgeval naar een medewerker, die er 3 minuten per stuk aan kwijt is: 6 uur. De tweede: hoeveel van die 280 blijken toch fout? Een hoge score op de eerste meting zegt daar niets over. Stel 3%: dan zitten er elke week ongeveer 8 verkeerde orders tussen.

Een steekproef van 1 op de 10 automatische orders, à 2 minuten, kost ongeveer 1 uur, maar vindt gemiddeld minder dan één van die 8 fouten. De rest merkt de klant: een verkeerde levering, een retour, een telefoontje. Reken je 15 minuten herstel per fout, dan komt daar 2 uur bij. Er blijft zo’n 9 uur per week over en er komt 31 uur vrij, met 8 klanten per week die een fout merken. Vind je dat te veel, dan moet de software beter of de controle strenger, en die controle kost weer tijd.

Daar trek je drie dingen van af: de bouwprijs, de maandelijkse kosten voor het model en de hosting, en de tijd van de eigenaar die de testset bijhoudt. En de 70% en de 3% zijn aannames tot je ze hebt gemeten. Zonder nulmeting en testset is elk getal in deze som een schatting.

Wat het oplevert volgens onderzoek

De best gemeten winst komt uit de klantenservice. Bij ongeveer 5.000 supportmedewerkers van een groot softwarebedrijf maakte een AI-assistent mensen gemiddeld 14% productiever, en de minst ervaren medewerkers 35% (NBER, Generative AI at Work). De winst zat vooral bij wie het werk nog leerde.

Wanneer je beter niet automatiseert

Automatiseren kost bouwtijd, onderhoud en aandacht. In deze gevallen raad ik het af.

Te zelden

Komt een taak minder dan wekelijks voor, dan verdien je de bouwkosten zelden terug.

Niet te controleren

Kun je de uitkomst niet nakijken, dan weet je niet of de automatisering het goed doet. Dan bouw je een risico.

Proces verandert

Wordt het proces binnenkort anders ingericht, automatiseer dan het nieuwe proces, niet het oude.

Het probleem zit ergens anders

Soms wordt bestaande software niet gebruikt. Dan levert uitleg en begeleiding meer op dan nieuwe software.

Vaste invoer

Ziet de invoer er elke keer hetzelfde uit, dan is een gewone regel goedkoper dan AI.

Wat de EU AI Act ervan vindt

De meeste automatisering in het mkb, zoals bestellingen, facturen of interne documenten, valt in de lichtste categorieën van de EU AI Act. Bij toepassingen over mensen ligt dat anders. Bij werving en selectie, ook als AI alleen sollicitaties analyseert of filtert en een recruiter beslist, en bij het beoordelen van de kredietwaardigheid van personen kan bijlage III van de verordening de toepassing als hoog risico indelen. Menselijk toezicht is dan een van de eisen, geen uitzondering op die indeling. Praat software rechtstreeks met klanten, dan moet je vermelden dat het AI is (artikel 50).

In mijn niveaus blijven beslissingen over mensen op niveau 1. Of de toepassing onder hoog risico valt en welke eisen dan gelden, toets ik apart, voordat er iets wordt gebouwd.