AIRO, VAIR en DPV voor aantoonbare AI-governance

Van een gedeelde risicotaal naar versiegebonden bewijs, controleerbare besluiten en gerichte herbeoordeling. Gebaseerd op arXiv:2610.31380, "AI Risk Ontologies for the EU AI Act Compliance" (Golpayegani, Pandit, O'Sullivan & Lewis, 2026).

---

Stel dat een organisatie een juridisch RAG-systeem vrijgeeft. Het risicodossier bevat een positieve beveiligingstest, een privacybeoordeling en een goedgekeurd besluit. Vervolgens verandert de zoekindex, krijgt een agent toegang tot een aanvullende bron en wordt het model vervangen.

Welke conclusies uit het eerdere dossier blijven geldig? Welke tests moeten opnieuw worden uitgevoerd? En kan de organisatie reconstrueren op welke systeemconfiguratie het oorspronkelijke besluit berustte?

Dat is een informatieprobleem én een bewijsprobleem. Een document kan correct beschrijven wat gisteren is beoordeeld, terwijl het onvoldoende zegt over het systeem dat vandaag draait.

De paper AI Risk Ontologies for the EU AI Act Compliance, van Delaram Golpayegani en collega's, biedt hiervoor een semantisch fundament. Mijn centrale stelling is dat de praktische waarde daarvan ontstaat wanneer we risicobegrippen verbinden met concrete systeemversies, toetsbare claims en herleidbaar bewijs.

Een organisatie moet uiteindelijk kunnen beantwoorden: welke uitspraak over dit AI-systeem wordt door welk bewijs ondersteund, onder welke voorwaarden, en wat verandert er wanneer die voorwaarden wijzigen?

1. De bijdrage van AIRO, VAIR en DPV

De drie namen hebben verschillende functies.

Bouwsteen	Functie	Betekenis voor een implementatie
AIRO, AI Risk Ontology	Relaties tussen AI-systemen, gebruikscontext, risico's en maatregelen	Een gemeenschappelijk model voor het beschrijven van risicoscenario's
VAIR, Vocabulary of AI Risks	Gespecialiseerde begrippen voor onder meer doelen, technieken, betrokkenen en risico's	Herbruikbare termen waarmee teams dezelfde zaken herkenbaar benoemen
DPV, Data Privacy Vocabulary	Breder vocabulaire voor gegevensverwerking, technologie en regelgeving	Verbinding tussen AI-risico-informatie en bestaande verantwoordingsinformatie

AIRO en VAIR kunnen zelfstandig worden gebruikt. De DPV-extensies voor AI en de AI Act bieden daarnaast een bredere integratieroute.

De auteurs ontwikkelen AIRO en VAIR iteratief met competentievragen, de LOT-methodiek en bronnen uit de AI Act en ISO-standaarden. AIRO omvat 56 klassen, 61 objectproperties en drie dataproperties; VAIR 402 klassen. De focus ligt op AI-systemen. Het afzonderlijke risicoregime voor GPAI-modellen wordt niet uitgewerkt.

Een competentievraag beschrijft welke vraag het model moet kunnen beantwoorden. Voor een organisatie zou dat bijvoorbeeld zijn: welke toepassingen gebruiken dezelfde component en welke risicobeoordelingen hangen daarvan af?

De technische winst zit in expliciete betekenis en relaties. CSV, JSON en SQL zijn eveneens machineleesbaar. Een ontologie verdient haar plaats wanneer gedeelde identifiers, begrippenhiërarchieën en uitwisseling tussen organisaties aantoonbaar meerwaarde bieden.

Wat de paper niet test

De evaluatie omvat één synthetische casus, Proctify, en twee gemodelleerde incidentcases, Uber RTID en VioGén. Daarnaast gebruiken de auteurs reasoners, OOPS en FOOPS voor kwaliteitscontrole. De studie rapporteert geen gecontroleerde productie-evaluatie van risicoreductie, auditkosten of juridische besliskwaliteit.

Dit onderscheid bepaalt wat je met het resultaat mag doen:

Onderzoeksvraag	Wat nog aangetoond moet worden
Kunnen onafhankelijke teams dezelfde risico's consistent modelleren?	Overeenstemming en analyse van annotatieverschillen
Wordt een onvolledig dossier eerder ontdekt?	Vergelijking met een even zorgvuldig ingericht alternatief
Vermindert de aanpak onterechte vrijgaven?	Evaluatie van besluiten en hun onderliggende bewijs
Blijft het model bruikbaar bij systeemwijzigingen?	Longitudinale meting van onderhoud en herbeoordeling

FOOPS beoordeelt FAIR-eigenschappen, Findable, Accessible, Interoperable en Reusable. Dat is een andere betekenis dan fairness als afwezigheid van discriminatie.

De vervolgvraag is daarmee empirisch: helpt deze structuur verantwoordelijken om betere en beter onderbouwde besluiten te nemen?

2. Modelleer de toepassing en het schademechanisme

Een modelnaam is een ontoereikende sleutel voor een risicobeoordeling. Hetzelfde taalmodel kan openbare publicaties samenvatten, interne dossiers doorzoeken of zelfstandig een handeling uitvoeren. Het risicoprofiel hangt mede af van gegevens, bevoegdheden, gebruikers en gevolgen.

Daarom stel ik voor de beoordeelde toepassing als een expliciete combinatie vast te leggen:

K = (systeemversie, model, prompt, bronmomentopname, tools, bevoegdheden, gebruikscontext)

Dit is een eigen toepassingsprofiel. Het maakt verschillen tussen configuraties expliciet. Een gekoppelde validatieregel kan vervolgens verhinderen dat bewijs zonder beoordeling wordt overgenomen.

Gebruik hierbij concrete revisies en onveranderlijke artifactidentiteiten. Leg voor een externe modeldienst vast welke versie de aanbieder daadwerkelijk bekendmaakt en welke instellingen zijn gebruikt. Waar de exacte implementatie onbekend blijft, hoort die onzekerheid bij het bewijs. Een versielabel garandeert geen deterministisch gedrag.

Binnen die context moet het risicomodel onderscheid maken tussen een bron van risico, een kwetsbaarheid, een gebeurtenis en de gevolgen voor betrokkenen. AIRO onderscheidt onder meer Risk Source, Vulnerability, Consequence en Impact. Het laatste begrip richt de aandacht op effecten op mensen, groepen, maatschappij en omgeving.

Neem een fictieve RAG-toepassing die documenten uit meerdere afgeschermde werkruimten ontsluit:

Onderdeel	Concrete invulling
Gebruikscontext	Een medewerker stelt vragen binnen werkruimte A
Kwetsbaarheid	De retriever past een autorisatiefilter onjuist toe
Gebeurtenis	Een passage uit werkruimte B wordt opgehaald
Direct gevolg	Het antwoord bevat informatie buiten de toegestane scope
Impact	Vertrouwelijkheid wordt geschonden en een betrokkene kan worden benadeeld
Maatregel	Autorisatie wordt bij retrieval en documenttoegang afgedwongen
Bewijs	Positieve en negatieve toegangstests op de relevante configuratie

Deze uitsplitsing voorkomt dat een label als "datalekrisico" het hele dossier vervangt. Ze maakt zichtbaar waar een maatregel ingrijpt en welke observatie haar werking zou kunnen ondersteunen.

Een risico-ontologie legt daarmee een verondersteld schademechanisme vast. Het opnemen van een relatie tussen maatregel en risico bewijst nog geen causaal effect. Daarvoor moeten alternatieve verklaringen, testcondities en veranderingen in blootstelling worden onderzocht.

Ook ernst en waarschijnlijkheid verdienen afzonderlijke onderbouwing. Een score van 1 tot 5 is zonder schaaldefinitie geen gemeten kans. Het vermenigvuldigen van twee ordinale scores levert geen gekalibreerde verwachte schade op.

Bewaar daarom de inschatting, de methode, onzekerheid en betrokken populatie. Een zeldzaam maar ernstig grondrechteneffect kan bestuurlijk relevant blijven, ook als een geaggregeerde score laag uitvalt.

Welke schade blijft buiten het model?

Een gedeelde taxonomie bevat keuzes over wat als risico telt. Als een dossier vooral financiële schade voor de organisatie registreert, kunnen ervaren uitsluiting, verlies van autonomie of beperkte toegang tot rechtsbescherming uit beeld verdwijnen.

Behandel de categorieën daarom als uitbreidbaar en betwistbaar. Laat betrokken perspectieven meewegen, documenteer waarom een schadecategorie wel of niet wordt opgenomen en bewaar minderheidsbeoordelingen. Een volledig ingevuld model is alleen volledig ten opzichte van zijn eigen afbakening.

3. Vier verschillende vormen van geldigheid

Een betrouwbaar ontwerp onderscheidt vier vragen:

Laag	Vraag	Geschikte toets
Semantische consistentie	Kunnen de opgenomen uitspraken tegelijk waar zijn binnen de gekozen axioma's?	Ontologieredenering
Dossiervolledigheid	Zijn de vereiste gegevens aanwezig en onderling passend?	SHACL of vergelijkbare validatie
Bewijskwaliteit	Zijn bronnen authentiek, methodologisch bruikbaar en toepasselijk?	Artifactcontrole en inhoudelijke evaluatie
Besluitkwaliteit	Rechtvaardigt het bewijs dit besluit binnen deze context?	Expliciete besluitregels en bevoegde beoordeling

Het onderscheid tussen de eerste twee is technisch essentieel. OWL werkt met een open-world assumption: een ontbrekend feit hoeft niet onwaar te zijn. Een dossier zonder benoemd testbewijs kan daardoor logisch consistent blijven. Ook een OWL-cardinaliteitsrestrictie dwingt niet vanzelf af dat de bedoelde informatie expliciet in het ingediende bestand staat.

SHACL kan voorwaarden aan een afgebakende RDF-graaf toetsen, zoals verplichte velden, cardinaliteiten en samenhang tussen waarden. Een geslaagde controle betekent dat de geselecteerde gegevens aan de ingestelde voorwaarden voldoen.

Dat is een beperkte maar bruikbare uitspraak. Als de verkeerde records worden geselecteerd, of een verplicht systeem ontbreekt in de export, kan een validatierapport slagen terwijl het dossier onvolledig is.

Daarom hoort naast validatie een dekkingscontrole: komen de systemen, releases en claims die volgens de bronregistratie beoordeeld moeten worden daadwerkelijk in de gecontroleerde momentopname voor?

Leg onbekendheid en tegenspraak afzonderlijk vast

Eén veld compliant: true verliest veel betekenis. Een bruikbaarder ontwerp onderscheidt bijvoorbeeld:

• Onbeoordeeld: er is nog geen beoordeling uitgevoerd.
• Onvoldoende onderbouwd: bewijs ontbreekt of is niet toereikend.
• Ondersteund: de claim is binnen een expliciete scope onderbouwd.
• Tegengesproken: er bestaat relevant tegenbewijs.

Tijdsgebonden geldigheid is daarnaast een eigen dimensie. Een eerder ondersteunde claim kan herbeoordeling vereisen zonder dat daarmee is bewezen dat de maatregel niet meer werkt.

Meerdere beoordelingen mogen naast elkaar bestaan. Een geslaagde test en een later incident hoeven niet door "de nieuwste status wint" te worden samengevoegd. Behoud beide, met hun scope en herkomst.

4. De juridische laag heeft een eigen levenscyclus

De AI Act bevat verschillende verplichtingen die om verschillende soorten informatie vragen.

Artikel 9 beschrijft voor toepasselijke high-risk-systemen een doorlopend risicomanagementproces. Artikel 11 verlangt actuele technische documentatie, met ten minste de toepasselijke onderdelen van Annex IV. Artikel 27 regelt een grondrechteneffectbeoordeling voor de daarin omschreven gebruiksverantwoordelijken en inzetcontexten.

Een gedeeld gegevensmodel kan deze werkzaamheden ondersteunen. De wettelijke toepasselijkheid moet afzonderlijk worden bepaald.

Voor de publieke sector is vooral het onderscheid tussen DPIA en FRIA relevant. Artikel 27(4) maakt het mogelijk relevante onderdelen van een DPIA via verwijzing of overname te benutten in de FRIA, voor zover daarmee verplichtingen uit dat artikel al zijn afgedekt. Dat ondersteunt hergebruik, terwijl de reikwijdte van beide beoordelingen verschillend blijft.

Ook standaardisatie vereist precisie. DPV is een Community Group-specificatie en vermeldt expliciet dat het geen W3C Standard is. Artikel 40 koppelt het vermoeden van conformiteit aan overeenstemming met geharmoniseerde normen, of delen daarvan, waarvan de referenties in het Publicatieblad zijn gepubliceerd. Dat vermoeden geldt voor de eisen of verplichtingen die deze normen afdekken.

Een verwijzing naar ISO-terminologie of een W3C-community geeft een ontologie dus geen zelfstandig juridisch keurmerk.

Peildatum 24 oktober 2026: volgens de Europese Commissie trad de AI Omnibus op 27 juli 2026 in werking. De Commissie vermeldt 2 december 2027 voor toepassing van de high-risk-regels voor Annex III en 2 augustus 2028 voor Annex I. Dit zijn geen universele ingangsdata voor alle AI Act-verplichtingen.

Dit onderstreept een concrete architectuurkeuze: versieer het vocabulaire, de juridische interpretatie en de uitvoerbare regels afzonderlijk.

De geraadpleegde DPV AI- en EU-AIACT-specificaties zijn versie 2.3, gedateerd 25 februari 2026. Die datum bewijst op zichzelf geen inhoudelijke fout, maar evenmin dat latere wetswijzigingen al zijn verwerkt.

Een controleerbaar besluit legt daarom vast:

• Welke systeemcontext is beoordeeld.
• Welke rechtsbron en versie zijn gebruikt.
• Welke interpretatie en uitzonderingen zijn toegepast.
• Welke regelset de controle uitvoerde.
• Welke actor het besluit nam en wanneer het opnieuw moet worden beoordeeld.

5. Rechtsbedeling laat zien waarom context doorslaggevend is

"Juridische RAG" is geen voldoende juridische classificatie.

De officiële AI Act Service Desk onderscheidt algemene zoekfunctionaliteit in jurisprudentie van systemen die concrete zaakfeiten analyseren, toepasselijke precedenten selecteren en voorstellen hoe het recht daarop wordt toegepast. Ook moet een samengestelde keten in haar totale configuratie worden beoordeeld.

Voor een fictieve toepassing betekent dit dat de overgang van zoeken naar inhoudelijke besluitondersteuning expliciet in het dossier moet worden verwerkt.

Wijziging	Vraag voor herbeoordeling
Van algemene trefwoorden naar zaakfeiten	Welke interpretatieve functie krijgt de toepassing?
Van zoekresultaten naar een conceptmotivering	Hoe beïnvloedt de output het besluitproces?
Van openbare bronnen naar afgeschermde dossiers	Welke gegevensgrenzen en bevoegdheden veranderen?
Van suggesties naar uitvoerende tools	Welke handelingen kan het systeem daadwerkelijk verrichten?

Een regel als model_id naar risicoklasse kan deze verschillen niet representeren. Een beter model verbindt het systeem aan zijn beoogde doel, feitelijke configuratie, betrokkenen en invloed op besluitvorming.

Menselijk toezicht moet daarbij observeerbaar worden gemaakt. De vermelding "een medewerker controleert de uitkomst" zegt weinig over de beschikbare tijd, informatie en bevoegdheid.

Voor een proefopstelling zou ik daarom onderzoeken of beoordelaars aantoonbare fouten herkennen, relevante bronnen controleren en een onjuist voorstel effectief kunnen herstellen. Daarbij moeten taakmoeilijkheid, tijdsdruk en gewenning worden meegenomen.

Het risico-object krijgt zo een relatie met de omstandigheden waarin toezicht daadwerkelijk kan werken. Dit is een ontwerpvoorstel voor evaluatie, geen resultaat dat deze paper heeft gemeten.

6. Van risicograaf naar bewijsvoering

Voor een agentplatform zou ik beginnen met een semantische projectie van bestaande registraties. Dat kan boven een relationele database en bestaande artifactopslag worden ingericht.

De volgende architectuur is een eigen uitwerking van de beschreven bouwstenen:

[Register en configuraties] ───────► [Versiegebonden claims] ──────┐
[Tests en operationele waarnemingen] ► [Bewijs met herkomst] ───────┤
[Rechtsbronnen en interpretaties] ───► [Versiebeheerde regels] ──────┤
                                                                    ▼
                                                            [Risicograaf]
                                                                    │
                                                                    ▼
                                                    [Validatie en impactanalyse]
                                                                    │
                                                                    ▼
                                                    [Besluit of herbeoordeling]
                                                                    │
                                                                    └──► (terug naar versiegebonden claims)

De bronregistratie bewaart welke configuratie draait. De graaf verbindt die configuratie met risico's, maatregelen, claims en bewijs. De beslislaag bepaalt wat uit die informatie volgt.

PROV-O biedt begrippen voor entiteiten, activiteiten en verantwoordelijke actoren, met relaties voor onder meer generatie en afleiding. Daarmee kan een testrapport worden verbonden aan de testuitvoering en de gebruikte inputs.

Herkomst en betrouwbaarheid blijven verschillende eigenschappen. Een hash ondersteunt een integriteitscontrole wanneer deze met een vertrouwde referentie wordt vergeleken. Hij bewijst niet dat de gemeten uitkomst correct is. Een handtekening kan de herkomst ondersteunen, terwijl de testopzet nog steeds ongeschikt kan zijn.

Voor iedere relevante claim stel ik daarom een minimaal bewijscontract voor:

Veld	Doel
Claim en afbakening	Vastleggen wat precies wordt beweerd
Systeem- en configuratie-identiteit	Bepalen waarop de claim betrekking heeft
Bewijsartifact en herkomst	Onderbouwing terugvinden en controleren
Evaluatiemethode en dekking	Begrijpen wat daadwerkelijk is getest
Uitkomst en onzekerheid	Het resultaat in passende sterkte formuleren
Regelversie en beoordelaar	De gevolgtrekking reconstrueren
Herbeoordelingsvoorwaarden	Weten welke wijzigingen relevant zijn

Een claim moet bovendien toetsbaar zijn. "Het systeem is veilig" is te breed. "Onder configuratie K leverden de gespecificeerde negatieve toegangstests geen documenten buiten de toegestane werkruimte op" is afgebakend genoeg om te onderzoeken.

Nul gevonden fouten is een beperkte observatie

Stel, uitsluitend als rekenvoorbeeld, dat 300 onafhankelijke tests met dezelfde faalkans nul lekken opleveren. De eenzijdige exacte 95%-bovengrens voor die kans is:

p_bovengrens = 1 - 0.05^(1/300) ≈ 0.00994

Dat is ongeveer 1%. De uitkomst bewijst dus geen foutkans van nul. Bovendien zegt de berekening alleen iets over het gekozen testproces. Gecorreleerde prompts, een beperkte aanvallersstrategie of een niet-representatieve corpusselectie maken de vertaling naar productie onzeker.

Bewaar daarom ook testdekking en afhankelijkheden. Anders verandert een precies geformuleerd testresultaat onderweg in een veel sterkere veiligheidsclaim.

7. Een compact RDF- en SHACL-voorbeeld

Onderstaand voorbeeld controleert één dossierregel: een als ondersteund geregistreerde claim en alle gekoppelde bewijsstukken moeten dezelfde versie-IRI gebruiken.

De dj:-termen zijn een eigen voorbeeldvocabulaire onder example.org. airo:AISystem, airo:Risk en airo:hasRisk komen uit AIRO. De objecten en resultaten zijn fictief.

@prefix ex:   <https://example.org/demo/> .
@prefix dj:   <https://example.org/djimit/governance#> .
@prefix airo: <https://w3id.org/airo#> .
@prefix prov: <http://www.w3.org/ns/prov#> .

ex:release17 a airo:AISystem ;
    airo:hasRisk ex:crossTenantLeakage .

ex:crossTenantLeakage a airo:Risk .

ex:claim17 a dj:SupportedClaim ;
    dj:forVersion ex:release17 ;
    dj:aboutRisk ex:crossTenantLeakage ;
    dj:evidence ex:report17 .

ex:report17 a prov:Entity ;
    dj:forVersion ex:release17 ;
    prov:wasGeneratedBy ex:testRun17 .

ex:testRun17 a prov:Activity .

De bijbehorende SHACL-shape luidt:

@prefix dj: <https://example.org/djimit/governance#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

dj:SupportedClaimShape a sh:NodeShape ;
    sh:targetClass dj:SupportedClaim ;
    sh:property [
        sh:path dj:forVersion ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:nodeKind sh:IRI
    ] ;
    sh:property [
        sh:path dj:evidence ;
        sh:minCount 1 ; sh:nodeKind sh:IRI ;
        sh:node [
            sh:property [
                sh:path dj:forVersion ;
                sh:minCount 1 ; sh:maxCount 1 ;
                sh:nodeKind sh:IRI
            ]
        ]
    ] ;
    sh:property [
        sh:path ( dj:evidence dj:forVersion ) ;
        sh:equals dj:forVersion
    ] .

De claim heeft exact één versie. Ieder bewijsstuk heeft eveneens exact één versie. De laatste constraint vereist dat alle via bewijsstukken gevonden versies gelijk zijn aan de claimversie.

Als report17 naar release16 verwijst, faalt deze controle. Ook één afwijkend bewijsstuk tussen meerdere passende stukken veroorzaakt een fout.

De shape controleert uitsluitend getypeerde SupportedClaim-instanties. Zonder doelinstanties kan een SHACL-rapport geldig zijn terwijl niets inhoudelijks is gecontroleerd. Daarom moet de eerder genoemde dekkingscontrole het verwachte aantal en de identiteit van claims bewaken.

Het voorbeeld controleert geen testinhoud, authenticiteit of juridische toereikendheid. De typering SupportedClaim is een geregistreerde bewering, geen uitkomst die de validator zelfstandig vaststelt.

8. Maak wijzigingen en bewijshergebruik expliciet

Een bewijsstuk blijft niet automatisch bruikbaar na iedere wijziging. Alles opnieuw beoordelen is evenmin een doelmatige standaard.

Modelleer daarom welke claim van welke eigenschap afhankelijk is.

Wijziging	Mogelijk geraakt bewijs
Nieuw embeddingmodel	Retrievalkwaliteit en vindbaarheid
Nieuwe autorisatieregels	Afbakening tussen gebruikers en werkruimten
Nieuwe tools of ruimere scopes	Grenzen aan uitvoerbare handelingen
Ander prompttemplate	Instructievolging en omgang met onbetrouwbare inhoud
Nieuwe bronverzameling	Representativiteit, herkomst en toegangsgrenzen
Gewijzigd gebruiksdoel	Juridische classificatie en impactbeoordeling
Nieuwe wettelijke interpretatie	Besluiten die op de eerdere interpretatie steunden

Dit overzicht beschrijft mogelijke afhankelijkheden. Een implementatie moet per claim vastleggen welke daadwerkelijk gelden.

Een wijziging leidt vervolgens tot een expliciete keuze: hergebruik is onderbouwd, aanvullende toetsing is nodig, of de eerdere claim wordt ingetrokken. Bewaar het oorspronkelijke besluit zodat ook de historische situatie reproduceerbaar blijft.

Wanneer bewijs van een eerdere configuratie wordt hergebruikt, registreer dan een afzonderlijke toepasselijkheidsbeoordeling voor de nieuwe configuratie. Die verwijst naar het oorspronkelijke bewijs; de oude bewijsidentiteit en scope blijven behouden. Het strikte versieprofiel uit het voorbeeld vraagt hiervoor dus een nieuw beoordelingsartifact.

Voor zelfverbeterende agents betekent dit dat een nieuwe skill, prompt of bevoegdheid een kandidaatconfiguratie oplevert. Een geslaagde taak in één context is geen algemene kwalificatie van de hele agent.

De ontologie kan helpen gerichte experimenten te kiezen. Als alleen de retriever verandert, kun je de daarop afhankelijke claims selecteren. Claims over infrastructuur kunnen buiten die selectie blijven wanneer de afhankelijkheidsanalyse dat rechtvaardigt.

Dat maakt de meerwaarde voor evolutie concreet: sneller bepalen welke bewijslast een verandering met zich meebrengt en welke kennis verantwoord kan worden hergebruikt.

Versioneer ook de betekenis

DPV gebruikt standaard RDFS en SKOS; er bestaat daarnaast een alternatieve OWL2-serialisatie met een andere namespace. De gekozen representatie moet dus onderdeel zijn van de reproduceerbare configuratie.

Leg ook mappings tussen vocabularia vast. SKOS onderscheidt bijvoorbeeld een nauwe overeenkomst van een exactere overeenkomst en van bredere of smallere begrippen.

Een intern label voor "privacyrisico" is niet zonder onderbouwing gelijk aan iedere juridische privacycategorie. Bewaar bij de mapping bronversies, richting, motivatie en geldigheidsgebied.

9. Beveilig de bewijsvoering tegen zelfbevestiging

Een agent die zowel een wijziging voorstelt, de test schrijft, de uitkomst interpreteert als het risicodossier bijwerkt, kan een gesloten kring van zelfbevestiging creëren.

Mijn ontwerpkeuze is daarom om voorstel, observatie, beoordeling en besluit als verschillende objecten te behandelen. De bron van een positief oordeel moet zichtbaar blijven. Twee agents die hetzelfde rapport overnemen leveren geen twee onafhankelijke bewijsstukken.

Een LLM kan kandidaatrisico's annoteren en relevante bronnen voorstellen. Een modeluitspraak behoort pas als onderbouwing te worden gebruikt wanneer duidelijk is welke bewijsfunctie zij vervult en hoe die functie wordt gecontroleerd.

Ook de technische toegang verdient afbakening. Voor een API naar de bewijsregistratie zou ik OIDC gebruiken voor gebruikersidentiteit en OAuth2-scopes beperken tot de noodzakelijke lees- of schrijffuncties. Houd toegangstokens kort geldig, controleer de bedoelde ontvanger en ontwerp intrekking en sleutelrotatie expliciet. Tokens en secrets horen niet als gewone graafgegevens te worden opgeslagen.

Vocabularia, mappings en shapes zijn eveneens softwareafhankelijkheden. Pin de gebruikte artifacts, beperk het automatisch ophalen van externe imports en controleer wijzigingen in de validatieregels.

Maak tenslotte onderscheid tussen gedeelde begrippen en toegankelijke informatie. Een interoperabel risicomodel verplicht niet tot het centraal opslaan of breed delen van alle onderliggende dossiers. Bewaar gevoelige bewijsstukken in hun bestaande toegangsgrens en deel alleen de noodzakelijke metadata.

10. Meet de meerwaarde met een eerlijk experiment

De ontologie moet worden vergeleken met een serieus alternatief.

Een bruikbaar onderzoeksontwerp heeft drie condities:

Conditie	Inrichting	Wat de vergelijking leert
A	Huidige werkwijze	Bestaande kwaliteit en inspanning
B	Gestructureerde relationele registratie met dezelfde bronkwaliteit, versiehistorie en bewijsregels	Winst door betere informatiehuishouding
C	Dezelfde inrichting, aangevuld met ontologieën en semantische relaties	Aanvullende waarde van de semantische laag

Het verschil tussen A en C alleen is onvoldoende om een effect aan ontologieën toe te schrijven. Verbeterde brondata, extra aandacht en explicietere procedures kunnen dezelfde uitkomst verklaren.

Verdeel taken en beoordelaars gerandomiseerd of in een gebalanceerd onderzoeksontwerp over de condities. Beperk leereffecten met vergelijkbare maar verschillende cases en laat de uitkomsten waar mogelijk blind beoordelen. Zo worden ervaring, casusmoeilijkheid en verwachtingen minder snel verward met de meerwaarde van de semantische laag.

Gebruik vooraf vastgelegde taken, zoals het beoordelen van een autorisatiewijziging, het terugvinden van onderbouwde claims en het herkennen van tegenstrijdig bewijs.

Voeg gecontroleerd fouten toe: een verkeerd release-ID, ontbrekend bewijs, een vervallen beoordeling, een gewijzigde regel en een tegenstrijdig incident. Laat onafhankelijke beoordelaars onder een vastgelegde interpretatie een referentieoordeel opstellen. Bewaar ook hun onzekerheid.

De primaire uitkomst is het aandeel ongeldige dossiers dat ten onrechte wordt geaccepteerd:

Onterechte acceptatie = geaccepteerde ongeldige dossiers / alle ongeldige dossiers

Meet daarnaast de tijd tot een correct besluit, gemiste afhankelijkheden, onnodige herbeoordelingen en totale onderhoudsinspanning. Rapporteer verschillen tussen systemen en beoordelaars, inclusief onzekerheidsintervallen. Wanneer één systeem meerdere taken levert, moet de analyse die onderlinge afhankelijkheid meenemen.

Overeenstemming tussen annotatoren verdient een eigen meting. Als deskundigen dezelfde bron verschillend modelleren, kan extra automatisering dat verschil eenvoudig reproduceren.

Dit experiment toetst of de aanpak bewijsvoering verbetert. Een claim over minder schade in de praktijk vraagt een aanvullend onderzoek naar operationele uitkomsten en blootstelling.

11. Een gerichte implementatie

Voor een eerste toepassing zou ik één concrete keten kiezen: een agent, een afgebakende bronverzameling en één wijziging waarvan het risico toetsbaar is.

Begin met vijf vragen die het huidige dossier moet kunnen beantwoorden:

1. Welke configuratie draait en welke handelingen zijn toegestaan?
2. Welke claims gelden voor deze configuratie?
3. Welk bewijs ondersteunt die claims en wat dekt het?
4. Welke wijziging maakt aanvullende beoordeling nodig?
5. Wie of welke bevoegde regel heeft het besluit genomen?

Projecteer vervolgens de relevante bestaande records naar RDF en gebruik AIRO, VAIR of DPV voor de begrippen die daadwerkelijk nodig zijn. Voeg een klein validatieprofiel toe en vergelijk de uitkomsten met de bronregistratie.

Laat de eerste uitvoering bestaande besluiten observeren. Onderzoek gemiste gegevens en verkeerde signalen voordat een controle onderdeel wordt van een automatische vrijgave.

Een afzonderlijke graphdatabase is pas gerechtvaardigd wanneer de benodigde queries, uitwisseling of inferentie daarmee aantoonbaar beter worden ondersteund. Dezelfde ontwerpprincipes kunnen aanvankelijk in een relationeel systeem worden gerealiseerd.

De zichtbare gebruikersinterface moet daarbij de onderbouwing ontsluiten: status, scope, bewijs, ontbrekende informatie en reden voor herbeoordeling. Een percentage "compliance" zonder deze context nodigt uit tot een sterker oordeel dan de gegevens dragen.

De bestuurlijke waarde van expliciet bewijs

AIRO, VAIR en DPV verdienen aandacht omdat ze een gedeelde taal bieden voor complexe verantwoordingsinformatie. De praktische opgave is die taal te verbinden met de veranderlijke werkelijkheid van software, data, agents en besluitvorming.

Een goed ontworpen systeem kan dan bij iedere wijziging laten zien welke claims worden geraakt, welk bewijs nog bruikbaar is en waar aanvullende beoordeling nodig is.

Dat maakt gerichtere autonomie mogelijk: veranderingen kunnen sneller worden verwerkt wanneer hun reikwijdte en onderbouwing zichtbaar zijn.

De vraag voor bestuurders en architecten is daarom concreet: kunnen we reconstrueren waarom een besluit op dat moment gerechtvaardigd was, en kunnen we herkennen wanneer de onderbouwing daarvan verandert?

Zie ook

• AI governance evidence pack
• AI Governance
• FRIA onder de EU AI Act: fundamentele-rechtenbeoordelingen vereisen bewijsbasis, de downstream-toepassing die AIRO, VAIR en DPV als bouwstenen gebruikt voor evidence-grounded beoordelingen.
• EU AI Act Digital Omnibus: high-risk-verplichtingen verschoven naar 2027 en 2028, de toepassingsdata die in dit artikel als peildatum zijn gebruikt.

Bronnen

1. AI Risk Ontologies for the EU AI Act Compliance: AIRO, VAIR, and their Integration with DPV, arXiv:2610.31380, Golpayegani, Pandit, O'Sullivan & Lewis, 22 oktober 2026
2. AIRO, AI Risk Ontology, W3ID permanent URL
3. VAIR, Vocabulary of AI Risks, W3ID permanent URL
4. Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
5. Regulation (EU) 2024/1689 (AI Act), EUR-Lex