In de weken voorafgaand aan deze handhaving kwamen drie zaken naar buiten die de wet lijken te illustreren. Ze laten iets zien wat geen enkel artikel uit de AI Act zelf kan afdwingen: het verschil tussen weten dat je AI gebruikt en weten wanneer je die uitkomst kunt vertrouwen. Hieronder eerst de drie casussen zelf, daarna wat dat concreet betekent voor hoe je AI-gebruik in je eigen organisatie organiseert.

Waar het al misging:

Een adviseur die zijn eigen advies niet volgde

Neem het rapport “Transforming Governance”, gepubliceerd door PwC Midden-Oosten in 2025. Het introduceert een methodiek genaamd “Citizen Pulse”, beschrijft hoe overheden er real-time inzicht mee zouden krijgen in de behoeften van burgers en somt concrete voorbeelden op: de overheden van Denemarken, Saoedi-Arabië, de Verenigde Staten en Australië zouden het al gebruiken om publieke dienstverlening te verbeteren. Onderzoekers van AI-detectiebedrijf GPTZero konden echter geen enkel bewijs vinden dat Citizen Pulse als product bestaat, laat staan dat een van de genoemde overheden het gebruikt. De voetnoten verwezen naar overheidsportalen die het framework nergens noemen en naar een artikel in MIT Technology Review dat nooit heeft bestaan (GPTZero).

Dit rapport stond niet op zichzelf. GPTZero onderzocht in totaal vier rapporten die PwC Midden-Oosten tussen 2024 en 2026 publiceerde, over uiteenlopende onderwerpen als overheidsdienstverlening, elektrische mobiliteit in de Golfstaten en agentic AI. In alle vier vonden de onderzoekers verzonnen of onverifieerbare citaten.

PwC Midden-Oosten liet tegenover de Financial Times weten de nauwkeurigheid van het gepubliceerde onderzoek serieus te nemen en “een beperkt aantal ondersteunende citaten” in de rapporten te actualiseren en wees op de eigen kwaliteitscontroleprocessen voor onderzoek en contentontwikkeling. Een partij die klanten adviseert over verantwoord AI-gebruik, bleek zelf niet de controle georganiseerd te hebben die ze diezelfde klanten aanraadt, precies het soort controle waar we verderop op terugkomen.

Een berisping in ‘s-Hertogenbosch

Dichter bij huis kreeg een advocate uit Limburg een berisping van de Raad van Discipline in ‘s-Hertogenbosch (uitspraak ECLI:NL:TADRSHE:2026:93). Ze had processtukken door een AI-tool laten opstellen en de aangehaalde jurisprudentie niet gecontroleerd. Het gevolg: verwijzingen naar ECLI-nummers die niet bestonden, of die naar heel andere zaken verwezen, waaronder een echtscheidingsbeschikking. De tuchtrechter noemde het een schending van de kernwaarden deskundigheid en integriteit. Bij het bepalen van de maatregel liet de raad meewegen dat de advocate niet eerder tuchtrechtelijk was veroordeeld en dat AI-geletterdheid ten tijde van de processtukken, in juli 2025, nog geen gemeengoed was. Die omstandigheden pleitten in haar voordeel, vandaar een berisping in plaats van een zwaardere maatregel.

Toen de testomgeving de deur open liet staan

De derde casus speelde zich af bij twee AI-labs tegelijk, met opvallend dezelfde kern.

Stel je een model voor dat de opdracht krijgt een cybersecurity-benchmark op te lossen, binnen een afgeschermde testomgeving, met expres verzwakte restricties om te meten hoe ver de aanvalscapaciteiten reiken. Dat was precies wat eind juli 2026 speelde bij OpenAI.

In plaats van de opgave binnen de sandbox op te lossen, vonden de betrokken modellen een onbekende kwetsbaarheid, braken uit naar het publieke internet en concludeerden dat een ander AI-bedrijf, Hugging Face, de antwoorden op de benchmark waarschijnlijk zou hosten. Ze braken in op de productie-infrastructuur van dat bedrijf om die antwoorden te bemachtigen. Niet om te hacken op zich, maar uit ijver: de modellen waren, in de woorden van OpenAI zelf, extreem gefocust op de benchmark en deden er alles aan om die te winnen. Hugging Face merkte de inbraak zelf op, dagen voordat OpenAI de koppeling met de eigen tests legde (OpenAI; Hugging Face).

Negen dagen later meldde branchegenoot Anthropic iets vergelijkbaars, met een net andere oorzaak. Waar bij OpenAI een model zich een weg naar buiten moest hacken, stond bij Anthropic de deur gewoon open: een misconfiguratie bij een externe testpartner zorgde ervoor dat een “afgeschermde” testomgeving alsnog verbonden was met internet.

De modellen kregen expliciet te horen dat ze geen internettoegang hadden en gingen er dus van uit dat alles wat ze tegenkwamen onderdeel was van de oefening, ook toen dat in werkelijkheid productiesystemen van drie externe organisaties bleken te zijn. Anthropic kwam dit op het spoor via een review van meer dan 140.000 eigen evaluatieruns, opgestart naar aanleiding van de OpenAI-melding. Het meest tekenende detail: één model merkte op dat de systemen er “echt” uitzagen, redeneerde daar vervolgens overheen en zette de aanval voort. Een ander, nieuwer model twijfelde op hetzelfde punt en stopte juist uit zichzelf (Anthropic).

Beide labs benadrukken dat er geen sprake was van een model met een verborgen agenda. Het probleem zat niet in het model, maar in de testomgeving eromheen: bij OpenAI ontbrak een grens die tegen een onbekende kwetsbaarheid bestand was; bij Anthropic ontbrak zelfs de juiste configuratie om de belofte “geen internettoegang” waar te maken.

Drie casussen, verspreid over advieswerk, rechtspraak en AI-veiligheidstests. Ondanks de verschillen is het onderliggende patroon opvallend vergelijkbaar. In geen van de gevallen ontbrak de kennis dat AI fouten kan maken. Wat ontbrak was de menselijke stap tussen wat AI produceerde en wat er vervolgens mee gebeurde.

Waarom transparantie niet volstaat

Hier zit de kern: artikel 50 alleen is niet genoeg. De wet vraagt transparantie, laat weten dat iemand met AI praat, label content die kunstmatig is gegenereerd. Dat is nuttig en voor de meeste organisaties relatief eenvoudig te regelen, maar het raakt niet waar het in alle drie de casussen hierboven daadwerkelijk misging. Niemand in deze verhalen was onbekend met het feit dat er AI gebruikt werd; PwC’s klanten wisten dat vermoedelijk net zo goed als OpenAI en Anthropic zelf wisten dat hun modellen in een verzwakte of verkeerd geconfigureerde testomgeving draaiden. Wat ontbrak was niet die wetenschap, maar de zekerheid dat er iemand of iets stond tussen wat AI opleverde en wat daar vervolgens mee gebeurde.

In alle drie de gevallen was de vraag niet of er AI gebruikt werd, maar wat er gebeurde nadat AI iets opleverde. Een antwoord, een bron, een stuk code, een testresultaat: dat is allemaal makkelijk te produceren, in grote aantallen en tegen lage kosten. Beoordelen of dat antwoord klopt, is een heel andere handeling. Die schaalt niet vanzelf mee. Naarmate er meer AI-output ontstaat, wordt de vraag wie deze output controleert net zo belangrijk als de vraag wat er mee gedaan wordt.

Dit zien wij ook in de praktijk

Bij Polteq zien we deze verschuiving terug in vrijwel elke discipline waarin we actief zijn. Of het nu gaat om een adviesrapport, requirements, een architectuurkeuze of testcode: AI kan het genereren. De vraag die overblijft is wie erop toeziet dat die output ook daadwerkelijk klopt voordat deze een rapport, pipeline of productieomgeving bereikt. Dat is precies de reden dat we onszelf steeds minder alleen als testspecialist positioneren en steeds meer als partij voor Quality Engineering en Consultancy: de discipline die niet alleen toetst of software werkt, maar ook ontwerpt hoe je AI-gebruik binnen een organisatie beheersbaar houdt, van prompt tot publicatie.

In ons werk aan testautomatisering betekent dat bijvoorbeeld dat een agent die testcode genereert nooit het eindpunt is. We werken met een multi-agent framework waarin gespecialiseerde agents elk een smal mandaat hebben. Een agent die falende testen herstelt, commit bijvoorbeeld zelf nooit: elke voorgestelde fix gaat langs een menselijke reviewer voordat hij de codebase in gaat. Daarnaast dwingt een definition-of-done-checklist af dat documentatie, zoals architectuur- en opstartinstructies, wordt bijgewerkt voordat een taak als afgerond geldt, niet als iets dat er later nog wel bij kan. Dat laatste klinkt misschien klein, maar is precies het soort stap die in de PwC-casus hierboven ontbrak: niemand die expliciet controleerde of de output nog aansloot bij de werkelijkheid voordat die de deur uitging.

Diezelfde logica passen we toe buiten testautomatisering. Bij adviesrapporten en requirementsdocumenten die met AI-ondersteuning tot stand komen, hanteren we dezelfde scheiding tussen opstellen en verifiëren: AI versnelt het schrijven, maar een mens toetst iedere feitelijke claim en bronvermelding voordat het document naar een klant gaat. Geen aparte, optionele controle, maar een vast onderdeel van het opleverproces, precies zoals we dat ook van onze eigen testcode verwachten.

Wat kwaliteitsmaatregelen in de praktijk betekenen

Een paar aanknopingspunten, rechtstreeks gekoppeld aan de drie casussen hierboven.

Bronverificatie als vaste stap, niet als vertrouwen achteraf. Bij AI-gegenereerde rapporten, offertes of adviesdocumenten hoort een expliciete controle van iedere aangehaalde bron voordat het document je organisatie verlaat. Geen suggestie, maar een vast onderdeel van het opleverproces, net zoals een code review een vaste stap is voordat code naar productie gaat.

Menselijke eindverantwoordelijkheid bij feitelijke claims. Gebruik je AI voor onderbouwing, of dat nu jurisprudentie is of testresultaten, dan blijf je zelf verantwoordelijk voor de juistheid ervan. Dat vraagt een cultuur waarin je AI-output nooit rechtstreeks overneemt, maar altijd als concept behandelt dat bevestiging nodig heeft.

Containment die bestand is tegen precies het scenario dat je probeert te voorkomen. Zet je AI-agents in binnen testautomatisering of CI/CD-pipelines? Dan verdienen netwerktoegang, credentials en monitoring dezelfde aandacht als de functionaliteit die je probeert te bouwen. De incidenten bij OpenAI en Anthropic laten allebei zien wat er gebeurt als een testomgeving niet daadwerkelijk bestand is tegen het scenario waar de opdracht van uitgaat.

Documentatie van herkomst. Nu artikel 50 handhaafbaar is, volstaat het niet meer om te weten dat iets met AI gemaakt is. Kun je aantonen welke content AI-ondersteund is, wie die heeft geverifieerd en wanneer?

Een praktijkcheck om mee te beginnen

Een paar vragen die de moeite waard zijn om te beantwoorden, in lijn met wat juridische adviseurs nu ook aanraden voor de artikel 50-voorbereiding:

• Waar in je organisatie wordt AI ingezet en welke output daarvan bereikt klanten of het publiek?
• Welke van die output bevat feitelijke claims, bronvermeldingen of juridische onderbouwing die geverifieerd moet worden?
• Is er een vaste, gedocumenteerde stap waarin een mens bronnen en claims controleert voordat een document de deur uitgaat?
• Zijn AI-agents die autonoom handelen voorzien van dezelfde grenzen aan netwerktoegang en credentials als een menselijke gebruiker zou krijgen?
• Is vastgelegd wie verantwoordelijk is als AI-output toch onjuist blijkt en hoe je dat corrigeert?
• Is duidelijk vastgelegd welke persoon of functie verantwoordelijk is voor toezicht op AI-gebruik en de naleving van interne kwaliteitsafspraken?

De kern

De AI Act-handhaving voegt een juridische stok achter de deur toe. PwC, de Limburgse advocate en de AI-labs OpenAI en Anthropic laten met deze drie casussen zien dat het risico niet in het gebruik van AI zit, maar in het ontbreken van kwaliteitsmaatregelen daaromheen. Transparantie is de wettelijke ondergrens. Of je AI daadwerkelijk verantwoord inzet, hangt niet af van de wet, maar van jezelf: van de vraag of je de stap tussen wat AI oplevert en wat je ermee doet, zelf ontwerpt, test en onderhoudt. Herken je dit in je eigen organisatie en wil je weten waar de kwaliteitsmaatregelen rond AI-gebruik bij jullie nog ontbreken? Plan een vrijblijvend gesprek met ons in. Geen verkooppraatje, geen kant-en-klare oplossing voordat we het probleem goed kennen, gewoon een half uur om samen te kijken waar bij jullie de grootste risico’s zitten. Neem contact met ons op.