AI Act Kompas

Artikel 15 stelt drie samenhangende eisen aan hoog-risico AI-systemen: een passend niveau van nauwkeurigheid, robuustheid en cyberbeveiliging, consistent gedurende de hele levenscyclus. Dit is de plek waar compliance en engineering elkaar direct raken.

Nauwkeurigheid: passend, gemeten en gepubliceerd

De AI Act noemt geen drempelwaarde. Wat "passend" is, hangt af van het beoogde doel en van de gevolgen van een fout. Een systeem dat medische beelden voorsorteert, heeft een ander foutbudget dan een systeem dat inkomende post rubriceert. Drie concrete verplichtingen:

• Je bepaalt vooraf welke maatstaven relevant zijn — nauwkeurigheid alleen zegt weinig bij ongebalanceerde data; precisie, recall, false-positive rate en prestaties per subgroep zeggen doorgaans meer.
• Je vermeldt het nauwkeurigheidsniveau en de maatstaven in de gebruiksaanwijzing (artikel 13). De deployer moet weten hoe betrouwbaar het systeem is.
• Je onderbouwt in de technische documentatie waarom die maatstaven geschikt zijn.

De Commissie werkt samen met belanghebbenden aan benchmarks en meetmethoden; volg de publicaties van het AI Office hierover.

Robuustheid: bestand tegen de echte wereld

Hoog-risico systemen moeten zo veerkrachtig mogelijk zijn ten aanzien van fouten, storingen en inconsistenties die zich kunnen voordoen binnen het systeem of de omgeving waarin het werkt — in het bijzonder door interactie met natuurlijke personen of andere systemen. Praktisch vertaalt dat zich in:

• Technische redundantie: back-upvoorzieningen of fail-safe-plannen die het systeem in een veilige toestand brengen als er iets misgaat.
• Gedrag bij onverwachte input: wat doet het systeem bij ontbrekende velden, extreme waarden of data in een ander formaat? Een expliciet "ik weet het niet"-antwoord is vaak veiliger dan een gefabriceerde uitkomst.
• Degradatiegedrag: als een externe dienst wegvalt, valt het systeem dan terug op een veilige modus of blijft het beslissingen produceren op basis van incomplete gegevens?
• Drift-detectie: monitoring op verandering in inputverdeling en prestaties over tijd.

Feedbackloops bij lerende systemen

Systemen die na de uitrol blijven leren, verdienen bijzondere aandacht. Als de output van het systeem de volgende trainingsronde voedt, kan een kleine vertekening zichzelf versterken. Denk aan een selectiesysteem dat kandidaten afwijst, waarna alleen de aangenomen kandidaten als "succesvol" terugkomen in de data. Artikel 15 verplicht om dit risico zoveel mogelijk weg te nemen en resterende loops met passende maatregelen te beheersen — bijvoorbeeld door gecontroleerde hervalidatie op onafhankelijke data en door menselijke correcties expliciet te labelen.

Cyberbeveiliging: AI-specifieke aanvallen

Artikel 15 lid 5 gaat verder dan generieke informatiebeveiliging. Het noemt expliciet aanvalsvormen die op de AI-componenten zelf zijn gericht:

• Data poisoning — het manipuleren van trainingsdata zodat het model onbedoeld gedrag aanleert.
• Model poisoning — het manipuleren van vooraf getrainde componenten die in de ontwikkeling worden gebruikt.
• Adversarial examples (model evasion) — inputs die speciaal zijn ontworpen om het model tot een verkeerde uitkomst te verleiden, vaak met voor mensen onzichtbare aanpassingen.
• Vertrouwelijkheidsaanvallen — pogingen om trainingsdata of modelparameters te reconstrueren, bijvoorbeeld via membership inference.
• Modelgebreken die door aanvallers kunnen worden uitgebuit.

De technische oplossingen moeten passend zijn bij de relevante omstandigheden en risico's. Denk aan herkomstcontrole en integriteitschecks op datasets en modelgewichten, inputvalidatie en anomaliedetectie, rate limiting, isolatie van modelendpoints, red-teaming en, bij taalmodellen, verdediging tegen prompt injection en het lekken van systeeminstructies.

Hoe je dit aantoonbaar maakt

1. Leg een testprotocol vast met de metrieken, drempels en datasets die je gebruikt, inclusief prestaties per relevante subgroep.
2. Voer adversarial tests uit en documenteer de resultaten — testlogboeken en testverslagen zijn expliciet onderdeel van bijlage IV.
3. Beschrijf de fail-safe-mechanismen en test ze periodiek, net als een noodstop bij machines.
4. Monitor in productie op prestaties, drift en afwijkende inputpatronen, en koppel de bevindingen terug in het risicobeheersysteem.
5. Neem beveiliging mee in wijzigingsbeheer: een modelupdate is ook een securitygebeurtenis.

Ontstaat er ondanks alles een ernstig probleem, dan komt artikel 73 over incidentmelding in beeld.

Veelgestelde vragen

Welke nauwkeurigheid eist de AI Act?

De verordening schrijft geen concreet percentage voor. Zij eist dat het systeem een passend niveau van nauwkeurigheid bereikt gezien het beoogde doel, en dat dat niveau plus de relevante maatstaven in de gebruiksaanwijzing worden vermeld. Wat passend is, onderbouw je in je risicobeheersysteem en je testprotocol.

Wat is data poisoning en waarom noemt de AI Act het?

Data poisoning is het opzettelijk manipuleren van trainingsdata om het gedrag van een model te sturen. Artikel 15 noemt het expliciet als aanvalsvorm waartegen technische oplossingen moeten worden getroffen, samen met model poisoning (manipulatie van vooraf getrainde componenten), adversarial examples (inputs die het model misleiden), model evasion en vertrouwelijkheidsaanvallen.

Wat moet ik doen bij systemen die blijven leren?

Systemen die na de uitrol blijven leren, moeten zo worden ontwikkeld dat het risico van vertekende output die volgende operaties beïnvloedt — feedbackloops — zoveel mogelijk wordt weggenomen en dat resterende loops met passende maatregelen worden aangepakt. In de praktijk betekent dat monitoring op drift, periodieke hervalidatie en het scheiden van modeloutput en trainingsinput.