De EU AI Act en je AI-servicedesk, in de praktijk

Wij zijn geen juristen, en dit is geen juridisch advies. Deze post is een praktische lezing van wat de EU AI Act meestal betekent voor een team dat AI op de servicedesk draait, geschreven vanaf de operationele kant. Het is bedoeld om je te helpen de juiste vragen te stellen en je eigen denken te ordenen. Voor alles wat een echte verplichting voor jouw organisatie wordt, ga je naar je eigen juridisch adviseur. We noemen hier geen artikelnummers of boetebedragen, want dat is precies het deel waarvoor je een jurist wilt en geen blogpost.

Dat gezegd hebbende: de dagelijkse werkelijkheid is minder dramatisch dan de koppen. De meeste servicedesk-AI is niet het soort hoog-risicosysteem waar de Act zich het meest zorgen over maakt, en veel van waar de Act op aandringt, transparantie, menselijk toezicht, gegevens bijhouden, is spul dat een goed geleide servicedesk toch al zou moeten doen. De waarde van de Act door een operationele bril lezen is dat het abstracte principes verandert in een korte checklist die je echt kunt aflopen.

Waar een servicedesk-AI meestal op de risicoschaal zit

De Act sorteert AI-systemen op hoeveel risico ze dragen. De zware kant gaat over dingen als systemen die iemands toegang tot essentiële diensten, hun veiligheid of hun juridische positie wezenlijk beïnvloeden. Een tool die IT-tickets trieert, antwoorden opstelt op "mijn VPN doet het niet" en kennisartikelen voorstelt zit ver van die kant van de schaal.

Dat betekent niet "er geldt niets." Het betekent dat de verplichtingen die het meest waarschijnlijk op jou van toepassing zijn de lichtere, verstandige zijn: wees transparant dat mensen met of via AI geholpen worden, houd een mens in de loop waar het ertoe doet, en kun laten zien wat het systeem deed. De zware conformiteitsmachinerie die op echt hoog-risicosystemen mikt is meestal niet waar een triage-assistent landt. Maar dit is een inschatting over jouw specifieke opzet, en precies daarom blijven we naar je eigen adviseur wijzen: hoe je het systeem gebruikt, en waarop het mag handelen, kan verschuiven waar je zit.

Een bruikbaar instinct: hoe meer een systeem iets onomkeerbaars met een mens kan doen zonder dat een mens meekijkt, hoe serieuzer je de indelingsvraag moet nemen. Een assistent die een antwoord opstelt dat een mens goedkeurt is iets heel anders dan een systeem dat zelf accounts blokkeert. Als jouw AI-servicedesk alles wat richting de klant gaat of onomkeerbaar is achter een menselijke beslissing houdt, heb je de veiligere keuze al gemaakt.

Transparantie richting eindgebruikers

Eén thema loopt consistent door de Act: mensen mogen niet misleid worden over de vraag of ze met een machine te maken hebben. In servicedesktermen is dat rechttoe rechtaan. Als een eindgebruiker een door AI opgesteld antwoord krijgt of een geautomatiseerde eerste reactie tegenkomt, moet redelijk duidelijk zijn dat er automatisering bij betrokken is, in plaats van het te laten lijken alsof een specifieke, met naam genoemde collega het intypte.

Dit is geen grote klus. Het gaat om hoe antwoorden geformuleerd zijn en hoe je portaal of kanaal geautomatiseerde reacties presenteert. De praktische toets is simpel: zou een normaal mens die de interactie leest begrijpen dat AI er deel van uitmaakte? Zo ja, dan zit je goed op het transparantie-instinct. Als je opzet automatisering actief vermomt als een mens, is dat het eerste om op te lossen, en het is een fix in woordkeuze en presentatie, niet in architectuur.

Menselijk toezicht, als configuratie

"Menselijk toezicht" klinkt als een governance-abstractie tot je het concreet maakt, en de concrete versie is degene die standhoudt. Op een goed geconfigureerde AI-servicedesk is toezicht geen beleidsdocument, het is een set instellingen.

Dat ziet eruit als een confidence-drempel per actietype: hoog voor alles wat een klant te zien krijgt, lager voor een interne suggestie, en een harde mens-alleen-regel voor alles wat onomkeerbaar is, zoals een account blokkeren of een wijziging maken die lastig terug te draaien is. Onder de drempel schrijft de AI zijn analyse als interne notitie in plaats van te handelen, en beslist een mens. Een gangbare manier om vertrouwen op te bouwen voordat er iets handelt is het geheel eerst in observeer-alleen modus draaien, waarbij de AI zijn analyse op echte tickets produceert maar geen uitgaande actie neemt, zodat je zijn oordeel kunt vergelijken met dat van je team. We schreven over dat uitrolpatroon in een AI-uitrol starten in shadow mode.

De reden dat dit voor de Act uitmaakt is dat "betekenisvol menselijk toezicht" veel makkelijker aan te tonen is als het een testbare, controleerbare configuratie is dan wanneer het een alinea in een beleidsstuk is. Je kunt naar de drempels wijzen, laten zien welke actietypes een mens vereisen, en de interne notities laten zien waar het systeem het uit handen gaf. Dat is toezicht dat je daadwerkelijk kunt bewijzen.

Logging en controleerbaarheid

Een terugkerende verwachting door de Act heen is dat je kunt reconstrueren wat een geautomatiseerd systeem deed en waarom. Voor een servicedesk betekent dat een helder overzicht: welk ticket, welke agent, wat het besloot, welke actie het nam of juist niet nam, en op welke basis.

Operationeel is dit gewoon goede hygiëne, en het is hetzelfde overzicht dat je helpt een slechte triage te debuggen of een beslissing aan een manager uit te leggen. De vraag over je eigen opzet is of dat spoor bestaat en op te halen is, niet begraven in een black box. Als een auditor, een klant, of je eigen team vraagt "waarom reageerde het systeem zo op dit ticket," wil je dat kunnen beantwoorden vanuit een log, niet vanuit een schouderophalen. Wanneer je een leverancier evalueert is dit een van de scherpere vragen om te stellen, en het scheidt een serieus product van een demo.

Data-residency in de EU

Naast de AI Act, en vaak in hetzelfde gesprek gebundeld, zit de vraag waar de data eigenlijk staat en verwerkt wordt. Voor de meeste EU-teams is dit eigenlijk een AVG-en-inkoopvraag in plaats van een AI-Act-vraag, maar het komt in dezelfde adem langs, dus het hoort hier.

De praktische punten zijn: weet in welke regio je ticketdata opgeslagen en verwerkt wordt, weet waar het AI-model dat je tickets leest draait en onder welke datavoorwaarden, en weet of persoonsgegevens bij enige stap de EU verlaten. Aan onze kant draaien we het platform op EU-infrastructuur en maskeren we gestructureerde persoonsgegevens voordat ze bij een AI-model komen, zodat het model op de kern van een ticket werkt zonder de rauwe persoonlijke details nodig te hebben. Hoe dat maskeren werkt staat in PII-maskering voor de servicedesk. Data-residency is niet iets wat je achteraf overtuigend kunt inbouwen, dus het is de moeite waard om het te bevestigen voordat je vastlegt, niet erna.

De vragen om aan je leverancier te stellen

Als je één ding uit deze post haalt, maak er dan een korte lijst vragen van om aan elke AI-servicedeskleverancier te stellen. Die sluiten direct aan op de thema's hierboven en snijden door veel marketing heen.

Vraag hoe over de risico-indeling van hun tool geredeneerd wordt, en of het zelf onomkeerbaar kan handelen. Vraag of gebruikers kunnen zien dat er AI bij betrokken is. Vraag hoe menselijk toezicht er concreet uitziet, drempels, mens-alleen-acties, een observeer-alleen modus, niet alleen het woord "human-in-the-loop" op een slide. Vraag wat er gelogd wordt en hoe je het ophaalt. Vraag waar data opgeslagen en verwerkt wordt, of het in de EU blijft, en hoe persoonsgegevens behandeld worden voordat een model ze ziet. Onze eigen antwoorden op de security- en compliancekant van die vragen staan in security en compliance voor een AI-servicedesk, en de onderliggende details in onze securitydocumentatie.

Een leverancier die die vragen kort en helder kan beantwoorden is er een waarop je een verdedigbare opzet kunt bouwen. Een leverancier die ze wegwuift vertelt je iets.

Veelgestelde vragen

Verbiedt de EU AI Act AI op de servicedesk?

Nee. Niets hier moet je lezen als "je mag geen AI voor tickets gebruiken." De Act gaat vooral over proportionele verplichtingen op basis van risico, en typische servicedeskondersteuning, triage, antwoorden opstellen, kennis voorstellen, zit ver van de zware kant. Bevestig je specifieke indeling met je eigen adviseur.

Is een triage-assistent een hoog-risico AI-systeem?

Meestal niet, maar het hangt af van hoe je het gebruikt en wat het zelf mag doen. Een systeem dat alleen opstelt en het aan een mens overlaat is iets heel anders dan een systeem dat onbeheerd onomkeerbare acties neemt. Dit is een inschatting voor je juridisch adviseur, niet iets om vanuit een blog te beslissen.

Moeten we gebruikers vertellen dat ze met AI praten?

Het transparantie-instinct in de Act wijst die kant op: mensen mogen niet misleid worden om te denken dat een machine een mens is. In de praktijk gaat dat over automatische reacties eerlijk formuleren in plaats van ze te vermommen. Het is een fix in woordkeuze en presentatie, niet in architectuur.

Wat moeten we een leverancier vragen over compliance?

Vraag naar risico-redenering, of het zelf onomkeerbaar kan handelen, transparantie richting gebruikers, concreet menselijk toezicht (drempels, mens-alleen-acties, een observeer-alleen modus), wat er gelogd wordt en hoe je het ophaalt, en waar data opgeslagen en verwerkt wordt, inclusief of het in de EU blijft en hoe persoonsgegevens gemaskeerd worden voordat een model ze ziet.

Echte service door echte mensen. De Act, nuchter gelezen, vraagt je vooral om een mens te houden waar het telt, eerlijk te zijn dat automatisering betrokken is, en je werk te kunnen laten zien. Dat is geen last, dat is een goed geleide servicedesk.