AI-compromittering is een datalek: hoe de impact te beperken wanneer een AI-systeem wordt misbruikt
Securityteams hebben jarenlang incident response opgebouwd rond een bekend dreigingsmodel: een gebruikersaccount wordt gecompromitteerd, een aanvaller krijgt toegang, laterale beweging begint.
Het draaiboek voor indamming is goed geoefend — isoleer het account, trek de inloggegevens in, bepaal de schade, meld indien nodig. Dat draaiboek moet worden uitgebreid, want AI-systemen zijn nu actoren in bedrijfsomgevingen met een fundamenteel ander dreigingsprofiel. Wanneer een AI-systeem wordt gecompromitteerd — via prompt injection, diefstal van inloggegevens, sessie hijacking of verkeerde configuratie — is het resultaat geen IT-incident. Het is een datalek.
De brede toegang van de AI tot serviceaccounts, gecombineerd met het vermogen om duizenden data-operaties per minuut uit te voeren, betekent dat het venster tussen compromittering en significante data-exposure wordt gemeten in minuten, niet in uren.
Deze post is voor CISO’s en securityteams die AI-compromittering als een assumed-breach scenario moeten behandelen en hun architectuur daarop moeten aanpassen.
Samenvatting voor Executives
Belangrijkste idee: Een gecompromitteerd AI-systeem met brede data-toegang is categorisch gevaarlijker dan een gecompromitteerd gebruikersaccount. Het operationele tempo waarmee AI data kan ophalen betekent dat traditionele, reactieve incident response controls — detecteren, indammen, herstellen — te laat komen. De blast radius moet architectonisch worden beperkt, vóórdat compromittering plaatsvindt, via controls die beperken wat een gecompromitteerde AI kan benaderen, ongeacht de instructies.
Waarom dit belangrijk is: De meeste enterprise AI-inzetten zijn niet ontworpen met compromittering als uitgangspunt. Het toegangsmodel, de sessiegrenzen en de audittrail zijn opgezet voor een functionerend AI-systeem dat werkt zoals bedoeld. Geen van deze ontwerpen houdt rekening met wat er gebeurt als de AI wordt gemanipuleerd, gehackt of onder controle van een aanvaller opereert. Het architecturale gat tussen “AI werkt correct” en “AI werkt tegen je” is precies wat blast radius containment moet dichten.
5 Belangrijkste Inzichten
- AI-compromittering is een datalek, geen IT-incident. Een gemanipuleerd of gehackt AI-systeem met brede repository-toegang kan data op een schaal en snelheid exfiltreren die veel verder gaat dan een gecompromitteerd gebruikersaccount — en de bijbehorende meldingsplicht aan toezichthouders is identiek.
- Blast radius is een architectonische eigenschap, geen operationele reactie. Tegen de tijd dat een SIEM-alert wordt opgepakt, kan een gecompromitteerde AI zonder ophaalbeperkingen al aanzienlijke data hebben verplaatst. Indamming moet in de architectuur zitten vóór compromittering, niet pas na detectie worden toegepast.
- Rate limiting op de datalaag is de meest effectieve blast radius-control voor AI-systemen. Het beperkt de hoeveelheid data, ongeacht de duur van de compromittering, waardoor bulkextractie architectonisch onmogelijk wordt in plaats van operationeel detecteerbaar.
- Per-request RBAC- en ABAC-autorisatie herdefinieert de blast radius van “alles wat het serviceaccount kan bereiken” naar “alles waar de huidige gebruiker toegang toe heeft”. Voor de meeste AI-inzetten betekent dit een orde van grootte minder potentiële blootstelling.
- Dual-attribution auditlogs zijn de forensische basis van AI-breach response. Zonder deze logs is het bepalen van de scope — wat is benaderd, via welke sessie, gedurende welke periode — giswerk. Met deze logs kan de scope van het datalek precies worden vastgesteld, meldingsplicht accuraat worden beoordeeld en herstel gericht worden uitgevoerd.
Waarom AI-compromittering niet te vergelijken is met gebruikersaccount-compromittering
Wanneer een gebruikersaccount wordt gecompromitteerd, krijgt een aanvaller de toegangsrechten van die gebruiker. Die rechten zijn begrensd door wat de gebruiker mag doen — begrensd door rol, dataclassificatie en het identity & access management-beleid van de organisatie. De aanvaller moet bovendien op menselijk tempo opereren: door bestandsstructuren navigeren, documenten openen, data handmatig exfiltreren. Anomaliedetectie krijgt de tijd om te werken. Een gebruiker die tien keer zoveel bestanden opent als normaal, triggert gedragsalerts. Het detectievenster is smal, maar bestaat.
Een AI-systeem-compromittering doorbreekt beide beperkingen tegelijk. Ten eerste de toegangsbeperking: de meeste enterprise AI-systemen draaien onder serviceaccounts met permissies die de volledige databehoefte van alle gebruikers dekken — veel breder dan een individueel gebruikersaccount.
Een gecompromitteerde AI is niet begrensd door de toegangsrechten van één gebruiker; alleen door wat het serviceaccount kan bereiken, wat vaak alles in de gekoppelde repository is. Ten tweede de tempobeperking: een gecompromitteerde AI werkt op machinesnelheid.
Prompt injection die een AI aanstuurt om alle documenten met een bepaald patroon op te halen, kan een repository leegtrekken in de tijd die het kost om een kop koffie te drinken. Er is geen menselijk gedragsprofiel om van af te wijken; “normale” AI-opvragingen kunnen er hetzelfde uitzien als bulkexfiltratie tot het hoeveelheidsdrempel een alert triggert — als die drempel überhaupt is ingesteld.
Het gevolg is een dreigingsmodel waar bestaande incident response-plannen niet voor zijn ontworpen. Detecteren-indammen-herstellen gaat uit van een detectievenster vóórdat er grote schade optreedt. Voor een gecompromitteerde AI met onbeperkte data-toegang kan er al aanzienlijke schade zijn binnen dat detectievenster.
De enige effectieve respons is om grote schade architectonisch onmogelijk te maken — de blast radius beperken vóór compromittering, zodat als de AI wordt misbruikt, de controls die blootstelling beperken al actief zijn.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het verifiëren?
Lees nu
Hoe AI-systemen worden gecompromitteerd: vijf aanvalsvectoren
Begrijpen van blast radius containment vereist inzicht in hoe AI-compromittering daadwerkelijk plaatsvindt. Het aanvalsvlak is breder dan de meeste securityteams aanvankelijk inschatten, en diverse van de belangrijkste vectoren hebben geen direct equivalent in traditionele gebruikersaccount-dreigingsmodellen.
| Aanvalsvector | Hoe werkt het tegen een AI-systeem | Detectievenster | Wat bepaalt de blast radius |
|---|---|---|---|
| Prompt Injection | Kwaadwillende instructies in content die de AI verwerkt sturen het gedrag om — waardoor ongeautoriseerde data-opvraging, blootstelling van inloggegevens of exfiltratie wordt getriggerd | Onmiddellijk; AI voert geïnjecteerde instructies uit zonder dat de gebruiker het merkt | Scope van serviceaccount-permissies; ontbreken van per-request autorisatie; locatie van credentialopslag |
| Gecompromitteerde AI-platform-inloggegevens | Aanvaller krijgt toegang tot het serviceaccount of de API-sleutels van het AI-systeem en gebruikt de AI als een volledig functioneel data-access tool | Hardnekkig tot inloggegevens worden geroteerd; kan dagen of weken onopgemerkt blijven | Breedte van serviceaccount-toegang; ontbreken van rate limiting; gat tussen AI-activiteit en SIEM-zichtbaarheid |
| Sessie Hijacking | Actieve gebruikerssessie wordt overgenomen; aanvaller gebruikt de geauthenticeerde sessie om AI-opvragingen te doen op data waar de gebruiker toegang toe heeft | Duur van de gehackte sessie | Sessielengte en frequentie van herauthenticatie; aanwezigheid van per-request autorisatie; rate limiting op opvragingen |
| Kwaadwillende RAG-poisoning | Aanvaller voegt kwaadaardige content toe aan de databronnen van een RAG-pijplijn, waardoor de AI valse of schadelijke informatie teruggeeft of data uit andere documenten lekt | Voortdurend tot de vergiftigde content is verwijderd | Integriteitscontroles op databronnen; outputmonitoring; isolatie tussen opgehaalde documenten in AI-context |
| Insider Threat via AI-versterking | Geautoriseerde gebruiker benut de brede serviceaccount-toegang van de AI om documenten op te halen buiten eigen autorisatie, via natuurlijke taalqueries | Verborgen; lijkt op normaal AI-gebruik tot hoeveelheidsanomalie wordt gedetecteerd | Per-gebruiker autorisatie op retrieval-laag; rate limiting; granulariteit van audittrail |
Prompt injection verdient bijzondere aandacht omdat het de aanvalsvector is die het meest uniek is voor AI-systemen en het meest wordt onderschat door securityteams.
In tegenstelling tot de andere vier vectoren vereist prompt injection geen compromittering van inloggegevens of sessie hijacking. Het enige vereiste is dat de AI content verwerkt met ingebedde instructies — een kwaadaardig document in de repository, een bewerkte e-mail die door de AI wordt opgehaald, een webpagina die wordt samengevat als onderdeel van een zoekopdracht.
De instructies van de aanvaller komen binnen in data die de AI legitiem moet verwerken, en de AI voert ze uit. Vanuit het perspectief van de AI volgt deze gewoon instructies. Vanuit het perspectief van het securityteam vertoont de AI onverwacht gedrag zonder zichtbare externe compromittering.
Het AI-risicoprofiel van prompt injection is direct gecorreleerd aan wat de AI kan benaderen. Een AI met beperkte, scope-gecontroleerde data-toegang, die geen inloggegevens kan bereiken en geen operaties buiten het toegestane domein kan uitvoeren, heeft een beperkt prompt injection-aanvalsoppervlak.
Een AI met brede serviceaccount-toegang, inloggegevens toegankelijk via de context, en zonder operationele restricties is een prompt injection-aanval die wacht op het juiste kwaadaardige document om te worden geactiveerd.
Blast radius is een architectonische eigenschap, geen operationele reactie
Het belangrijkste inzicht dat securityteams moeten internaliseren over AI-compromittering is dat de blast radius wordt bepaald bij inzet, niet bij het incident. De controls die bepalen hoeveel schade een gecompromitteerde AI kan aanrichten zijn architecturale keuzes — rate limiting, per-request autorisatie, credential-isolatie, scope-controls — die wel of niet aanwezig zijn in de inzet.
Tegen de tijd dat een compromittering wordt gedetecteerd, zijn deze controls óf al actief om de schade te beperken, óf de data is al verplaatst.
Dit is een wezenlijk andere manier van denken dan securityteams gewend zijn bij risicobeheer cyberbeveiliging. Voor de meeste dreigingen is de respons — hoe snel je detecteert, hoe effectief je indamt, hoe volledig je herstelt — de belangrijkste factor voor de omvang van het datalek.
Voor AI-compromittering op machinesnelheid is respons alleen onvoldoende als primaire control. Een SIEM-alert die twee minuten na het begin van een anomalie afgaat en vijf minuten later wordt opgepakt, betekent een venster van zeven minuten waarin een gecompromitteerde AI met onbeperkte toegang tienduizenden retrieval-operaties kan uitvoeren. Architecturale controls die het aantal opvragingen op de datalaag beperken, onafhankelijk van AI-gedrag, sluiten dat venster voordat het open gaat.
Vergelijk het verschil in omvang van een datalek tussen twee architecturen. In de eerste draait een AI onder een serviceaccount met toegang tot 500.000 documenten over alle bestandsdelen, zonder rate limiting, alleen sessie-autorisatie en auditlogging die alleen de serviceaccount-identiteit registreert.
Een prompt injection-aanval draait 20 minuten voordat deze wordt gedetecteerd. Scope: mogelijk honderdduizenden documenten benaderd, forensisch niet te bepalen, meldingsplicht onduidelijk. In de tweede werkt dezelfde AI via een beheerde data gateway met per-request RBAC- en ABAC-handhaving, rate limiting, credential-isolatie in de OS keychain en dual-attribution auditlogging.
Dezelfde prompt injection-aanval draait 20 minuten. Scope: begrensde opvragingen, volledig opgesomd in de auditlog, beperkt tot de geautoriseerde data van de huidige gebruiker. De architecturale controls bepaalden het resultaat vóórdat de aanval begon.
Zes blast radius containment-controls — en wat ze veranderen
| Containment-control | Hoe werkt het | Wat voorkomt het | Impact op blast radius |
|---|---|---|---|
| Rate limiting op de datalaag | Per-gebruiker en per-sessie opvraaglimieten afgedwongen door de data gateway — onafhankelijk van AI-systeemgedrag of instructies | Beperkt de hoeveelheid data, ongeacht de duur van de compromittering; maakt bulkextractie architectonisch onmogelijk | Zonder: duizenden documenten per minuut. Met: opvraaghoeveelheid begrensd, ongeacht AI-status. |
| Per-request RBAC/ABAC-autorisatie | Elke AI-data-opvraag wordt geëvalueerd op basis van de actuele toegangsrechten van de geauthenticeerde gebruiker — niet alleen op sessieniveau | Zorgt dat een gecompromitteerde AI geen data kan benaderen buiten de actuele rechten van de gebruiker, zelfs met volledige credential-toegang | Zonder: scope van serviceaccount bepaalt blast radius. Met: individuele gebruikersrechten bepalen blast radius. |
| Credential-isolatie in OS keychain | OAuth 2.0-tokens opgeslagen buiten het AI-contextvenster; niet toegankelijk via prompt injection of context-extractie | Elimineert credential theft als aanvalspad; prompt injection kan geen tokens ophalen, ongeacht de complexiteit van de instructie | Zonder: prompt injection levert bruikbare credentials op. Met: credential theft via AI is architectonisch geblokkeerd. |
| Pad- en scope-controls | Absolute padrestricties en whitelisting van operaties afgedwongen op de datalaag; AI kan niet buiten de bedoelde scope navigeren | Voorkomt laterale beweging naar systeembestanden, administratieve data of repositories buiten het bedoelde werkdomein van de AI | Zonder: elk pad dat het serviceaccount kan bereiken. Met: alleen het expliciet toegestane datadomein. |
| Realtime SIEM-integratie | Alle AI-operaties direct naar SIEM zonder batching; anomaliedetectie-baseline voor AI-opvraaggedrag | Minimaliseert het detectievenster; maakt geautomatiseerde respons mogelijk vóórdat bulkextractie voltooid is | Zonder: datalek ontdekt nadat data is verplaatst. Met: detectie en respons binnen de actieve sessie. |
| Dual-attribution auditlogging | Elke AI-operatie wordt gelogd met AI-systeemidentiteit en menselijke gebruikersidentiteit; volledig forensisch spoor vanaf het eerste verzoek | Maakt precieze scopebepaling na incident mogelijk; identificeert welke gebruikerssessies betrokken waren en exact wat is benaderd | Zonder: “AI-serviceaccount heeft bestanden benaderd” — scope onbekend. Met: volledige opvraaginventaris voor incident response. |
Na compromittering: welke forensische mogelijkheden zijn echt nodig?
Zelfs met sterke blast radius containment creëert AI-compromittering forensische en meldingsverplichtingen die nauwkeurige scopebepaling vereisen. Het verschil tussen een meldingsplichtig datalek en een ingedamd beveiligingsincident hangt vaak af van of je precies kunt aantonen welke data is benaderd — en die bepaling hangt volledig af van de kwaliteit van je AI-audittrail.
De minimale forensische capaciteit voor AI-breach response vereist antwoorden op vier vragen:
- Welke data is benaderd: welke specifieke bestanden, documenten of records heeft de gecompromitteerde AI opgehaald?
- Wie was betrokken: welke gebruikerssessies waren actief tijdens de compromitteringsperiode, en van welke gebruiker werd de autorisatie gebruikt bij elke opvraging?
- Wat was de tijdlijn: wanneer begon het afwijkende gedrag, en wat is de volledige volgorde van operaties van de eerste verdachte actie tot detectie?
- Viel de toegang binnen de autorisatiegrenzen: was de data bij elke opvraging binnen de scope van wat de sessie van de gebruiker mocht benaderen?
- Blog Post
Zero‑Trust Strategieën voor betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt in AI-databeveiliging - eBook
AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025 - Blog Post
Er is geen “–dangerously-skip-permissions” voor jouw data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.
Standaard AI-auditlogs — serviceaccount, timestamp, bestand benaderd — beantwoorden delen van vraag één en drie. Ze beantwoorden niet vraag twee (welke gebruiker), en kunnen vraag vier (was het geautoriseerd) niet beantwoorden omdat autorisatie nooit per-request werd geëvalueerd.
Voor HIPAA-naleving bij meldingsplicht van datalekken, waarbij moet worden vastgesteld welke PHI betrokken was en welke individuen zijn getroffen, leiden onvolledige audittrails direct tot overnotificatie — meer mensen informeren dan daadwerkelijk getroffen zijn omdat de scope niet precies kan worden bepaald.
Voor GDPR-naleving bij meldingsplicht van datalekken, waarbij toezichthouders binnen 72 uur moeten worden geïnformeerd met een beschrijving van de getroffen data, is een audittrail die alleen meldt “AI-serviceaccount heeft bestanden benaderd” geen toereikende basis voor de verplichte documentatie.
Dual-attribution logging — AI-systeemidentiteit en geauthenticeerde menselijke gebruikersidentiteit, bij elke operatie — maakt van “AI-serviceaccount heeft bestanden benaderd” een forensisch bruikbaar verslag.
Gecombineerd met per-request autorisatielogging die bijhoudt of elke opvraging was toegestaan of geblokkeerd, ontstaat een compleet beeld: wat is benaderd, door welke sessie, of het geautoriseerd was, in welke volgorde. Dat is het verslag dat precieze scopebepaling, accurate notificatie en verdedigbare documentatie van het datalek ondersteunt.
Hoe Kiteworks AI-compromittering architectonisch voorkomt
De securityteams die AI-adoptie het meest effectief beheren zijn niet degenen met de snelste incident response — het zijn de teams waarvan de AI-inzet zo is ontworpen dat een gecompromitteerde AI überhaupt geen catastrofaal datalek kan veroorzaken. Dat vereist dat AI-compromittering als een ontwerpbeperking wordt gezien, niet als een randgeval. Elke architecturale beslissing die bepaalt wat een functionerende AI kan benaderen, bepaalt ook wat een gecompromitteerde AI kan beschadigen. Het is één en dezelfde architectuur.
Kiteworks bouwt blast radius containment in de Private Data Network-architectuur op elk niveau. Rate limiting op AI-data-opvragingen wordt afgedwongen op het niveau van de data gateway, onafhankelijk van AI-systeemgedrag — een gecompromitteerde AI kan niet op bulkextractie-schaal ophalen, ongeacht de instructies.
Per-request RBAC- en ABAC-autorisatie via de Kiteworks Data Policy Engine zorgt dat de blast radius wordt begrensd door de toegangsrechten van de huidige gebruiker, niet door de scope van het serviceaccount — waardoor potentiële blootstelling wordt teruggebracht van repository-breed naar gebruiker-specifiek.
OAuth 2.0-inloggegevens worden opgeslagen in de OS keychain, niet toegankelijk via prompt injection of context-extractie onder welke omstandigheid dan ook, waardoor credential theft als blast radius-versterker wordt geëlimineerd.
Pad- en scope-controls blokkeren AI-navigatie buiten het bedoelde datadomein — systeembestanden, administratieve repositories en out-of-scope datastores zijn architectonisch onbereikbaar, ongeacht hoe prompts zijn opgebouwd of gemanipuleerd.
En dual-attribution auditlogs voeden het Kiteworks CISO Dashboard en integreren realtime met SIEM — geen batching, geen throttling — zodat als er iets misgaat, het forensische verslag voor scopebepaling, notificatie en documentatie van het datalek volledig en direct beschikbaar is.
Hetzelfde zero trust gegevensuitwisselingsframework dat beveiligd delen van bestanden, beveiligde MFT en beveiligde e-mail binnen de organisatie regelt, geldt voor elke AI-interactie — zodat AI wordt beheerst door dezelfde zero trust databeveiligingsstatus als elk ander datakanaal, en niet als een apart en minder gereguleerd kanaal.
Voor CISO’s en securityteams die AI-compromittering als een assumed-breach scenario willen behandelen en hun architectuur daarop willen aanpassen, biedt Kiteworks de controls die catastrofale AI-datalekken architectonisch onmogelijk maken.
Wil je zien hoe dit werkt in jouw omgeving? Plan vandaag nog een demo op maat.
Veelgestelde vragen
Twee factoren maken AI-compromittering categorisch schadelijker. Ten eerste de toegangsscope: AI-systemen draaien doorgaans onder serviceaccounts met rechten die de volledige databehoefte van alle gebruikers dekken — veel breder dan een individueel gebruikersaccount. Ten tweede het operationele tempo: een gecompromitteerde AI voert duizenden data-opvragingen per minuut uit, terwijl een gecompromitteerd menselijk account beperkt is tot navigatie op menselijk tempo. De combinatie betekent dat bulkdata-exfiltratie kan plaatsvinden binnen een detectievenster dat bij een gecompromitteerd gebruikersaccount minimale schade zou opleveren. Effectieve incident response voor AI-compromittering vereist architecturale blast radius-beperkingen, niet alleen snellere detectie.
Prompt injection is een aanval waarbij kwaadaardige instructies worden ingebed in content die de AI verwerkt — een document in de repository, een e-mail opgehaald tijdens een workflow, een webpagina samengevat als onderdeel van een zoekopdracht. De AI interpreteert deze ingebedde instructies als legitieme opdrachten en voert ze uit, mogelijk met het ophalen en blootstellen van data die de gebruiker nooit had willen benaderen. Omdat de aanval binnenkomt via legitieme content in plaats van externe systeemtoegang, kan deze volledig perimetercontrols omzeilen. Databeveiliging tegen prompt injection vereist credential-isolatie (zodat geïnjecteerde instructies geen authenticatietokens kunnen extraheren) en per-request autorisatie (zodat geïnjecteerde opvraginstructies worden begrensd door de daadwerkelijke toegangsrechten van de gebruiker).
Rate limiting, afgedwongen op de data gateway — onafhankelijk van de instructies of het gedrag van het AI-systeem — beperkt de hoeveelheid data die een gecompromitteerde AI kan ophalen, ongeacht hoe lang de compromittering duurt of welke instructies worden uitgevoerd. Zonder rate limiting kan een venster van 20 minuten tegen een AI met brede repository-toegang leiden tot catastrofale data-exposure. Met rate limiting op de datalaag levert hetzelfde venster van 20 minuten een begrensde, opsombare set opvragingen op die precies kan worden bepaald voor beoordeling van het datalek en meldingsplicht aan toezichthouders. Rate limiting is de enige architecturale control die de omvang van een AI-datalek het meest direct transformeert van potentieel catastrofaal naar definitief begrensd.
Effectieve AI-datalekforensiek vereist vier categorieën informatie: welke data is benaderd (specifieke bestanden en records opgehaald), wie was betrokken (welke geauthenticeerde gebruikerssessies waren actief en stuurden elke opvraging aan), de volledige tijdlijn (volgorde van operaties van eerste afwijkende actie tot detectie) en autorisatiestatus (of elke opvraging binnen de toegestane scope van de gebruikerssessie viel). Standaard auditlogs op serviceaccountniveau beantwoorden delen van vraag één en drie, maar niet twee of vier. Dual-attribution logging — het vastleggen van zowel AI-systeemidentiteit als geauthenticeerde menselijke gebruikersidentiteit bij elke operatie, samen met per-request autorisatiebeslissingen — levert het complete forensische beeld dat nodig is voor scopebepaling, meldingsplicht en incidentherstel.
Onder HIPAA-naleving wordt een AI-beveiligingsincident een meldingsplichtig datalek wanneer er ongeautoriseerde toegang is tot PHI die niet aantoonbaar een laag waarschijnlijkheidsrisico op compromittering heeft — en de bewijslast ligt bij de verantwoordelijke partij. Onder GDPR-naleving moet een datalek dat waarschijnlijk risico oplevert voor individuen binnen 72 uur worden gemeld aan toezichthouders. In beide gevallen beïnvloedt het vermogen om aan te tonen dat toegang beperkt en ingedamd was — via rate limiting, per-request autorisatie en nauwkeurige audittrail-documentatie — direct of een incident de meldingsdrempel overschrijdt en hoe de meldingsplicht wordt afgebakend. Organisaties zonder gereguleerde AI-audittrails lopen zowel een grotere kans om de meldingsdrempel te overschrijden als minder mogelijkheden om de scope van de melding te beperken zodra dat nodig is.
Aanvullende bronnen