De Europese AI-verordening en KIFF Cloud

1. Wat deze pagina is

Een mapping tussen specifieke functies van KIFF Cloud en specifieke artikelen van de AI-verordening. Elk deel over een functie noemt wat KIFF Cloud vandaag biedt, en ook wat we niet bieden, zodat de mapping niet kan worden gelezen als een garantie dat de klant aan de regels voldoet.

Waar deze pagina naar de AI-verordening verwijst, is de gezaghebbende tekst de tekst die de Europese Unie publiceert op EUR-Lex. Waar deze pagina daarvan afwijkt, geldt EUR-Lex.

2. Voor wie deze pagina is

Aanbieders en gebruiksverantwoordelijken van AI-systemen met een hoog risico in de zin van artikel 6 en bijlage III van de AI-verordening, tot wier verplichtingen traceerbare logging (artikel 12) en doeltreffend menselijk toezicht (artikel 14) behoren. KIFF Cloud is ontworpen om juist bij die twee verplichtingen te helpen; de andere verplichtingen uit de AI-verordening blijven de verantwoordelijkheid van de klant.

3. Artikel 12, Logging

Artikel 12 van de AI-verordening vereist dat bij AI-systemen met een hoog risico “gebeurtenissen gedurende de levensduur van het systeem automatisch worden geregistreerd (‘logs’)”, in een mate die volstaat om situaties die een risico opleveren te kunnen vaststellen, voor traceerbaarheid en voor monitoring na het in de handel brengen.

Wat KIFF Cloud biedt

• Automatische registratie van gebeurtenissen voor elke actie onder governance, event_ingested, state_changed, decision_recorded, action_validated, action_executed, approval_required, approval_granted, approval_denied, action_blocked.
• Toeschrijving per record: elke gebeurtenis draagt de identificator van de actor, het tijdstempel en de trace-id die haar met haar causale keten verbinden.
• Een auditketen waaraan alleen kan worden toegevoegd, op het niveau van het framework; opnieuw afspelen is deterministisch.
• Samenvattende hashes waaraan manipulatie te zien is, gepubliceerd in een openbaar, verifieerbaar spoor (als de implementatie voor de modus met het verifieerbare spoor kiest).
• Ondertekende Ontvangstbewijzen per actie onder governance, bruikbaar als bewijs buiten de eigen database van KIFF Cloud.

Wat KIFF Cloud niet biedt

• Beslissingen over wat er wordt gelogd. De domeinconfiguratie en de actiecontracten van de klant bepalen welke gebeurtenissen worden gegenereerd.
• Bewaartermijnen. Standaard wordt bewaard zolang de tenant van de klant bestaat; het beleid van de klant bepaalt of dat voldoet aan de toets “passend voor het beoogde doel” van artikel 26, lid 6 (ten minste zes maanden).
• Geautomatiseerde melding aan toezichthoudende autoriteiten op grond van artikel 73. De klant is verantwoordelijk voor elke melding naar buiten.
• Een oordeel over de vraag of het systeem van de klant volgens bijlage III als systeem met een hoog risico geldt. Die classificatie is aan de klant.

4. Artikel 14, Menselijk toezicht

Artikel 14 van de AI-verordening vereist dat AI-systemen met een hoog risico “zodanig ontworpen en ontwikkeld [worden] … dat hierop tijdens de periode dat zij worden gebruikt, op doeltreffende wijze toezicht kan worden uitgeoefend door natuurlijke personen”. Daartoe behoort dat een aangewezen toezichthoudende persoon de output kan interpreteren, in de werking kan ingrijpen en de werking zo nodig kan stilzetten.

Wat KIFF Cloud biedt

• Een goedkeuringsvereiste per actie. Elk ActionContract geeft zijn goedkeuringsvereiste aan (Required, OptionalIfHigh of None). Vereiste goedkeuringen zetten de uitvoering stil tot een aangewezen mens het voorstel heeft beoordeeld.
• Een plek om goedkeuringen te beoordelen. Het dashboard en de API tonen openstaande goedkeuringen met de volledige causale context: de gebeurtenissen waar het mee begon, de huidige toestand, de voorgestelde actie met haar parameters en de regel die het vasthouden heeft veroorzaakt.
• Toeschrijving aan de beoordelaar. Elk record approval_granted of approval_denied draagt de identificator van de beoordelaar, het tijdstempel en een veld voor een reden in vrije tekst.
• Een weigering is definitief. Een geweigerde goedkeuring blokkeert elke latere uitvoering van hetzelfde voorstel in dezelfde context. De klant kan een toezichtsbeslissing niet per ongeluk omzeilen door het opnieuw te proberen.
• Velden in het Ontvangstbewijs. Het Ontvangstbewijs van een actie die goedkeuring vereiste, legt de toeschrijving aan de beoordelaar vast, zodat het toezicht zichtbaar is voor auditors en toezichthouders verderop in de keten.

Wat KIFF Cloud niet biedt

• Opleiding van de menselijke beoordelaar. Artikel 26, lid 2, vereist dat de personen aan wie het toezicht is opgedragen, beschikken over “de nodige bekwaamheid, opleiding en autoriteit”; voor die bekwaamheid zorgt de klant.
• De bepaling welke acties toezicht vereisen. De domeinconfiguratie van de klant legt de goedkeuringsvereisten vast; KIFF Cloud handhaaft wat de configuratie aangeeft.
• Organisatiebeleid. Artikel 14, lid 2 en lid 3, legt toezichtsverplichtingen bij de organisatie van de gebruiksverantwoordelijke; KIFF Cloud kan niet in de plaats van die verplichtingen komen.
• Een “stopknop” op het niveau van het AI-systeem. KIFF Cloud werkt op het niveau van de actie; om het bredere systeem stil te zetten zijn de eigen beheersmaatregelen van de klant nodig.

5. Andere relevante artikelen

Naast de artikelen 12 en 14 raakt KIFF Cloud een aantal andere verplichtingen in mindere mate. Elke notitie hieronder noemt het artikel en de grens van onze bijdrage.

Artikel 9, Risicobeheer

Het veld risk_score van het Ontvangstbewijs is gereserveerd voor gegevens over eerdere uitkomsten over tenants heen. In v0.1 is het null, omdat de dataset nog niet is opgebouwd. Klanten kunnen vandaag niet op dit veld vertrouwen.

Artikel 10, Data en datagovernance

Buiten het bereik. De trainings-, validatie- en testdata van de klant zijn de verantwoordelijkheid van de klant.

Artikel 13, Transparantie naar gebruiksverantwoordelijken

Het formaat van het Ontvangstbewijs geeft afnemers verderop in de keten een gestructureerd beslissingsrecord dat ze kunnen lezen en controleren; sommige gebruiksverantwoordelijken vinden dat, afhankelijk van hun scenario, voldoende als bewijs van transparantie naar eindgebruikers.

Artikel 15, Nauwkeurigheid, robuustheid, cyberbeveiliging

De eigen cyberbeveiliging van KIFF Cloud is beschreven op /security. De nauwkeurigheid en robuustheid van het AI-systeem van de klant zijn de verantwoordelijkheid van de klant; KIFF Cloud is een governancelaag, geen model.

Artikel 17, Kwaliteitsbeheer

Buiten het bereik. Het systeem voor kwaliteitsbeheer van de klant is de verantwoordelijkheid van de klant.

Artikel 26, Verplichtingen van gebruiksverantwoordelijken

Veel verplichtingen van gebruiksverantwoordelijken vragen om bewijs van monitoring en toezicht. De auditketen en de Ontvangstbewijzen van KIFF Cloud zijn ontworpen om dat bewijs te zijn.

6. Wat niet op deze lijst staat

KIFF Cloud is een governancelaag voor acties van AI-systemen. Het gaat niet over verplichtingen die voortkomen uit het model zelf (herkomst van trainingsdata, tests op bias, modeldocumentatie), uit het organisatiebeleid van de gebruiksverantwoordelijke (werkwijzen voor het melden van incidenten, registratie als gebruiksverantwoordelijke) of uit infrastructuur voor monitoring na het in de handel brengen die verder gaat dan gelogde gebeurtenissen.

Als je conformiteitsbeoordeling verplichtingen aanwijst die hier niet aan bod komen, is KIFF Cloud daarvoor niet het juiste gereedschap. Dat zeggen we in een verkoopgesprek, in plaats van iets anders te suggereren.

7. Het Ontvangstbewijs als bewijs

Eén Ontvangstbewijs van KIFF verzamelt, voor één actie onder governance:

• de causale keten: de gebeurtenissen, de toestand, de beslissing en de validatie van de actie die tot de uitkomst hebben geleid (bewijs van logging volgens artikel 12);
• de toeschrijving aan de beoordelaar als menselijke goedkeuring vereist was (bewijs van toezicht volgens artikel 14);
• de versie van het beleid waaronder de beslissing is genomen (traceerbaarheid over de levensduur volgens artikel 12, lid 2, punt b));
• een cryptografische verklaring over de keten, te verifiëren los van de database van de cloud (integriteit volgens artikel 15).

Voor een toezichthouder die één actie onderzoekt, is er één Ontvangstbewijs; voor een toezichthouder die een systeem over langere tijd onderzoekt, de set ontvangstbewijzen. De stabiele JSON-vorm van het Ontvangstbewijs is bedoeld om die uitwisseling mechanisch te maken in plaats van beschouwend.

8. Beperkingen

We zijn geen aangemelde instantie, geen geaccrediteerde conformiteitsbeoordelaar en geen gemachtigde in de zin van de AI-verordening. We certificeren geen systemen van klanten. De conformiteitsbeoordeling volgens artikel 43 van de AI-verordening blijft de verantwoordelijkheid van de klant. De rol van KIFF Cloud is bewijs te leveren waarop de conformiteitsbeoordeling van de klant kan steunen.

Als de secundaire wetgeving bij de AI-verordening (gedelegeerde handelingen, uitvoeringshandelingen, geharmoniseerde normen) wordt bijgewerkt, kan deze mapping achterlopen. We werken deze pagina bij naarmate de regelgeving en de relevante richtsnoeren van de Commissie zich ontwikkelen.

9. Versiebeheer

Deze mapping heeft versies. v0.1 volgt de geconsolideerde tekst van de AI-verordening die is gepubliceerd in PB L van 12 juli 2024 en de richtsnoeren van de Commissie die beschikbaar waren op de datum in de kop.

10. Contact

Vragen over compliance: legal@kiff.dev. Vragen over privacy: privacy@kiff.dev. Beveiligingsmeldingen: security@kiff.dev.

Documentversie: v0.1.
Laatst bijgewerkt: 24 mei 2026.