Niet automatiseren is ook een ontwerpkeuze
De meeste verhalen over een digitale balie gaan over wat het systeem allemaal wél doet: een melding sorteren, een tijdslot voorstellen, een vraag meteen beantwoorden. Minstens zo belangrijk is het moment waarop het systeem, midden in een melding, bewust niets van dat alles doet en teruggeeft aan een mens of een bestaande noodlijn.
· ontwikkeling · 6 min · Mats Ponte
Als ik een digitale balie bouw, gaat het eerste gesprek met een opdrachtgever meestal over snelheid: hoe snel een melding wordt opgepakt, hoe snel een tijdslot verschijnt, hoe snel een standaardvraag een antwoord krijgt. Dat is ook waar het systeem het grootste deel van de tijd mee bezig is. Er is een ander moment dat minder vaak ter sprake komt en dat ik minstens zo belangrijk vind: het moment waarop het systeem, middenin een lopende melding, bewust niet doorpakt en het terugverwijst naar een mens of een bestaande noodlijn.
Niet omdat de techniek het niet aan zou kunnen, maar omdat het antwoord daar simpelweg niet hoort. Dat onderscheid leg ik niet achteraf vast, als een uitzondering die ik tegenkom tijdens het testen. Ik leg het vooraf vast, voordat er ook maar één gewone melding wordt afgehandeld.
Een storing die nooit wordt ingepland
In een demo-omgeving die ik heb gebouwd voor een installatiebedrijf begint elke storingsmelding met dezelfde eerste vraag: is er een veiligheidsrisico. Gaslucht, een afgaande CO-melder, roet of brandlucht bij elektra, waterschade bij een stopcontact. Zodra iemand daar iets gevaarlijks op aangeeft, breekt het scherm de intake meteen af. Er wordt geen tijdslot voorgesteld, er wordt niet doorgevraagd naar naam of adres, en de eigen storingsdienst komt nergens in beeld.
In plaats daarvan verschijnt direct het landelijke storingsnummer voor gas en stroom, 0800-9009, met bij direct gevaar de aanwijzing om 112 te bellen. Dat is geen verzonnen nummer voor de demo: het is het echte, landelijke nummer waarop netbeheerders in Nederland gaslucht en stroomstoringen laten melden.
Dat de melding daarmee stopt, betekent niet dat hij verdwijnt. Er landt een regel op de werklijst van de volgende ochtend: dat er iemand is doorgestuurd, met tijdstip en met welk antwoord diegene kreeg, zonder verdere persoonsgegevens. De reden staat letterlijk in de opzet: een melding die stilletjes verdwijnt is erger dan een melding die niet wordt aangenomen. Het systeem verstopt de afbreking niet, het legt hem vast.
Een bericht dat nooit inhoudelijk wordt beantwoord
Een vergelijkbare grens zit in een vraagbaak die ik heb gebouwd voor een zorgpraktijk. Daar controleert het systeem elk getypt bericht op een vaste lijst crisistrefwoorden: crisis, suïcide, geen zin meer om te leven, en vergelijkbare signalen. Komt zo'n woord voor, dan geeft de assistent nooit een inhoudelijk antwoord, ook geen geruststellend antwoord. De gebruiker krijgt in plaats daarvan uitsluitend de crisisroute van de praktijk zelf: de eigen huisarts, buiten kantooruren de huisartsenpost, en bij acuut gevaar 113, de Nederlandse hulplijn voor zelfmoordpreventie.
Een iets lichtere grens erboven vangt klinische of persoonlijke vragen op, zoals een vraag over medicatie. Ook daar geeft het systeem geen half antwoord, maar zet het het bericht door naar de praktijk. In beide gevallen is de keuze wat de assistent juist niet zegt minstens zo belangrijk als wat hij wel weet.
Waarom dit ook een wettelijke eis is, niet alleen mijn voorkeur
Dit is inmiddels niet meer alleen een kwestie van zorgvuldig ontwerp. De Europese AI-verordening schrijft in artikel 14 voor dat een hoogrisico-AI-systeem zo gebouwd moet zijn dat een mens er effectief toezicht op kan houden, en dat degene die dat toezicht houdt op elk moment kan besluiten om het systeem niet te gebruiken of de uitkomst ervan naast zich neer te leggen. Een digitale balie in de zorg of bij crisissignalen valt precies in de categorie waar die eis het zwaarst weegt.
Wat ik in de twee voorbeelden hierboven bouw, is in de kern niets anders dan die eis vooraf ingebakken: het systeem mag zelf beslissen om níet te beslissen, en die beslissing gaat automatisch naar een mens of een bestaande hulplijn. Ik wacht dus niet tot een toezichthouder of een incident me dwingt die grens te trekken. Ik trek hem bij de eerste versie, omdat de wet het vraagt en omdat het, los van de wet, het enige verantwoorde ontwerp is.
Waarom dit geen tekortkoming is
Het is verleidelijk om automatisering te verkopen als een systeem dat alles zelf oplost. Dat klinkt indrukwekkend, maar bij een noodgeval is het precies het verkeerde verhaal. Een systeem dat nooit nee durft te zeggen, dat bij een gaslek toch een tijdslot voorstelt of bij een crisissignaal toch een geruststellend antwoord probeert te formuleren, is geen slim systeem. Het is een systeem dat niet weet waar zijn eigen grens ligt, en dat is precies waar vertrouwen op breekt.
Beide voorbeelden hierboven zijn daarom bewust zo gebouwd dat ze op drie punten hetzelfde doen: de melding wordt niet zelf ingepland of beantwoord, de doorverwijzing gaat altijd naar een mens of een bestaande noodlijn, en de gebeurtenis wordt zichtbaar vastgelegd in plaats van stil te verdwijnen. Dat zijn geen gaten in de functionaliteit die ik nog moet dichten. Het zijn de regels die ik het eerst vastleg, vóór er ook maar één gewone melding wordt afgehandeld.
Hoe ik die grens test voordat het systeem live gaat
Een afbreekregel die alleen op papier bestaat, is geen afbreekregel. Voordat een digitale balie live gaat, stel ik samen met de opdrachtgever een vaste set testmeldingen samen die precies op de grens zitten: een storingsmelding met een terloopse verwijzing naar gaslucht, een bericht dat begint als een gewone vraag en halverwege omslaat. Bij elk van die testmeldingen hoort een vooraf vastgelegd goed antwoord, en dat antwoord is bijna nooit een uitgebreide, vriendelijke reactie. Het is de korte, saaie doorverwijzing.
Die set blijft daarna bestaan en gaat opnieuw mee bij elke wijziging aan het systeem: een nieuwe versie van het onderliggende model, een uitbreiding met een nieuw type melding, een aanpassing in de intake. Zo controleer ik niet alleen of de gewone meldingen goed worden afgehandeld, maar ook, bij elke wijziging opnieuw, of de afbreekregel nog steeds als eerste wordt getoetst en niet is weggeschoven door iets nieuws dat er later bij is gekomen.
Wat dit voor u betekent als opdrachtgever
Als u overweegt een digitale balie of een vraagbaak te laten bouwen, is de vraag die ik u aan het begin stel niet alleen wat het systeem allemaal moet kunnen afhandelen. Het is ook: welke situaties mag het systeem nooit zelf afhandelen, en waar moet het altijd teruggeven aan een mens of een bestaande route. Die lijst is meestal korter dan u denkt, maar hij moet er wel liggen voordat de eerste versie wordt opgeleverd, niet erna.
Vraag bij elke leverancier die u dat belooft door: welke meldingen zijn getest op afbreken, niet alleen op goed afhandelen, en wat gebeurt daarna met die melding. Kan de leverancier dat niet in een paar zinnen laten zien, dan is die grens vermoedelijk nooit expliciet vastgelegd, en dat ontdekt u dan liever nu dan bij de eerste echte crisismelding.
Een digitale balie die tijd bespaart, is nuttig. Een digitale balie die weet wanneer tijd besparen niet het punt is, is waar vertrouwen begint.
Bronnen
- ACM ConsuWijzer, over het landelijke storingsnummer 0800-9009 bij gaslucht of een andere storing https://consument.acm.nl/elektriciteit-en-gas/ik-heb-een-probleem/ruik-gas-in-huis-of-heb-andere-storing
- 113 Zelfmoordpreventie, de Nederlandse hulplijn bij crisissignalen https://www.113.nl/
- Verordening (EU) 2024/1689 (AI-verordening), artikel 14 over menselijk toezicht bij hoogrisico-AI-systemen https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
Beeld: Eigen werk, Aether AI · Geen licentie van derden nodig
