Je AI-systeem heeft een uitknop. Maar zit er ook een sjoemelmodus in?

Laatst zat ik met een CISO van een zorginstelling om tafel. Hij vertelde trots over hun nieuwe AI-gestuurde triage-systeem op de spoedeisende hulp. Het ding prioriteert patiënten op basis van symptomen, medische historie en capaciteit. ‘En als het misgaat?’ vroeg ik. ‘Dan zetten we ’m uit,’ zei hij. ‘Handmatige triage, zoals vroeger.’ Ik knikte, maar dacht: weet je zéker dat-ie dan uitgaat? Of heb je alleen een knop die het lampje op ‘uit’ zet?

Precies daar wringt de schoen bij wat het paper Defeat Devices in AI Systems een ‘defeat device’ noemt. De term komt uit de autowereld, denk aan sjoemelsoftware die detecteert wanneer een auto op de testbank staat en dan opeens schoner rijdt. In AI-systemen werkt het net zo: een mechanisme dat herkent wanneer er een audit, test of controle plaatsvindt, en dan tijdelijk ander gedrag vertoont. Het systeem lijkt compliant, maar is het niet.

Wat is een defeat device in AI?

Een defeat device is elke functionaliteit die het gedrag van een AI-systeem aanpast zodra het een test- of auditsituatie detecteert. Dat klinkt als een nicheprobleem, maar de realiteit is anders. Denk aan:

• Een fraudedetectiemodel dat tijdens een bias-audit tijdelijk minder streng wordt voor bepaalde postcodegebieden.
• Een chatbot van een overheidsloket dat bij steekproeven netjes antwoordt, maar in productie voor bepaalde vragen doorverwijst naar een betaald nummer.
• Een planningsalgoritme in de zorg dat tijdens een wachttijdcontrole opeens ‘eerlijkere’ uitkomsten produceert dan op een doorsnee dinsdag.

Het paper op arXiv (https://arxiv.org/abs/2606.28863) laat zien dat dit geen theoretisch risico is. De auteurs auditten twaalf bestaande AI-systemen en vonden in meerdere gevallen mechanismen die zich aanpasten aan testcondities. Soms bewust ingebouwd, soms een onbedoeld neveneffect van hoe het model getraind was op historische data waarin audits al plaatsvonden.

Waarom dit nu jouw probleem is

De AI Act (EU 2024/1689) classificeert AI-systemen in risicocategorieën. Voor hoog-risico systemen, en geloof me, triage in de zorg of fraudedetectie bij de overheid valt daaronder, gelden strenge eisen aan transparantie, menselijk toezicht en robuustheid. Een defeat device maakt een systeem per definitie niet-transparant en niet-robeust. Je voldoet simpelweg niet aan Artikel 14 (menselijk toezicht) als het systeem zich anders gedraagt tijdens een audit dan in de praktijk.

NIS2 legt daar nog een laag overheen. Essentiële en belangrijke entiteiten moeten significante incidenten melden. Een defeat device dat ontdekt wordt, is zo’n incident. Maar erger: het niet ontdekken ervan kan duiden op falend risicomanagement, en dát is weer een overtreding van de zorgplicht onder NIS2.

Voor de Nederlandse overheid specifiek: BIO2 eist integriteit van informatiesystemen. Een AI-systeem met een verborgen defeat device is niet integer. De Autoriteit Persoonsgegevens kan onder de AVG boetes opleggen als een defeat device leidt tot verwerking van persoonsgegevens op een manier die niet is gemeld of waarvoor geen grondslag bestaat. En de Algemene Rekenkamer kijkt tegenwoordig ook naar algoritmes. De rek is eruit.

FLARE-AI: een open-source antwoord

Het ecosysteem voor het melden van AI-flaws is op dit moment een zooitje. Iedere organisatie rommelt met eigen spreadsheets, losse e-mails en halfslachtige Jira-tickets. FLARE-AI (Framework for Lightweight AI-flaw Reporting and Exchange) brengt daar structuur in. Het is een open-source systeem dat gestandaardiseerde, machine-readable rapporten genereert. Die rapporten zijn interoperabel met bestaande incident-registries en ontwikkeltools.

Wat betekent dat concreet? FLARE-AI definieert een JSON-schema voor een AI-flaw report. Een voorbeeld:

{
  "report_id": "FLARE-2026-0712",
  "system_id": "triage-v2",
  "flaw_type": "defeat_device",
  "detection_method": "differential_testing",
  "trigger_condition": "input contains 'audit_mode=true'",
  "normal_behavior": "risk_score