Skip to main content

AI-verordening naleving in uw CI/CD-pipeline

Wat de verordening eist en een CI/CD-pipeline kan onderbouwen, drie pipelinefasen, hoe de GitHub merge gate van Scanara werkt en waar regelgebaseerde scans ophouden.

De verordening eist geen CI/CD. Aanbieders van hoogrisico-AI-systemen moeten de technische documentatie actueel houden (artikel 11) en testen vóór het in de handel brengen of in gebruik stellen (artikel 9(8)). Ze moeten ook een kwaliteitsbeheersysteem hanteren (artikel 17). Een pipeline kan bewijs voor deze plichten leveren.

Deze plichten gelden vanaf 2 december 2027 (bijlage III) en vanaf 2 augustus 2028 (bijlage I). Artikel 2 noemt uitzonderingen. De boetes bedragen maximaal 15 miljoen EUR of 3 % van de wereldwijde jaaromzet, als dat bedrag hoger is (artikel 99(4)). Volgende stap: koppel elke pipelinefase aan het artikel dat ze onderbouwt.

Een pipeline kan deze plichten onderbouwen; ze beslist niet over naleving

  • Technische documentatie blijft actueel (artikel 11)

    De technische documentatie wordt opgesteld vóór het in de handel brengen of in gebruik stellen en actueel gehouden. Ze bevat minstens de elementen van bijlage IV. Een pipelinestap kan controleren of de vereiste documenten bestaan en samen met de code veranderen.

  • Tests vinden plaats vóór het in de handel brengen of in gebruik stellen (artikel 9(6) tot en met (8))

    Er wordt op elk moment tijdens de ontwikkeling getest en in elk geval vóór het in de handel brengen of in gebruik stellen, aan de hand van vooraf vastgestelde metrieken en probabilistische drempels die bij het beoogde doel passen. Testfasen in de pipeline met vaste drempels leveren gedateerde resultaten op.

  • Kwaliteitsbeheer omvat wijzigingsbeheer (artikel 17(1))

    Het kwaliteitsbeheersysteem documenteert ontwerpbeheersing, kwaliteitscontrole van de ontwikkeling, onderzoeks-, test- en validatieprocedures en het beheer van wijzigingen. Pipelinelogs en reviewregels kunnen deze stappen vastleggen.

  • Substantiële wijzigingen vereisen een nieuwe conformiteitsbeoordeling (artikel 43(4))

    Een wijziging van een systeem na het in de handel brengen die de oorspronkelijke conformiteitsbeoordeling niet had voorzien en die de naleving van de vereisten van afdeling 2 aantast of het beoogde doel wijzigt, is een substantiële wijziging (artikel 3, punt 23). Een pipeline kan wijzigingen aan het model of het beoogde doel markeren voor menselijke beoordeling. Ze beslist niet of een wijziging substantieel is. Bij systemen die na het in de handel brengen blijven leren, zijn wijzigingen die bij de eerste beoordeling vooraf zijn bepaald en volgens bijlage IV, punt 2, f), zijn gedocumenteerd, geen substantiële wijzigingen (artikel 43(4)).

Drie pipelinefasen die bij deze plichten passen (ons voorstel)

De verordening noemt geen pipelinefasen. Deze indeling plaatst snelle controles op elke pull request en de volledige scan vóór de release.

Fase 1: controles bij de pull request

Ze draaien bij elke pull request en geven ontwikkelaars snel feedback.

  • Codescan: Regelgebaseerde statische analyse markeert AI-componenten en ontbrekende patronen, bijvoorbeeld AI-bewerkingen zonder logging. Ze herkent alleen standaardpatronen van ML-frameworks.
  • Documentcontrole: Beleidsregels controleren of de vereiste documenten bestaan en de vereiste onderdelen bevatten. Ze controleren of inhoud aanwezig is, niet of ze waar of goed is.
  • Vastlegging van de risicoklasse: Controleer of de risicoclassificatie van het systeem is vastgelegd en wordt herzien als de code of het beoogde doel verandert. De classificatie zelf is een menselijke beslissing (artikel 6).

Fase 2: merge gate

Een controle vóór de merge die niet-conforme wijzigingen kan tegenhouden.

  • Drempels voor bevindingen: Stel drempels in voor kritieke en hoge bevindingen. In blokkerende modus laat een scan boven de drempels de controle mislukken.
  • Bevindingen over artikel 5 en artikel 14: Een codescan toont geen opzet of context. Een mens beoordeelt elke bevinding die wijst op een verboden praktijk (artikel 5) of ontbrekend menselijk toezicht (artikel 14).
  • Wijzigingen in de documentatie: Controleer of de documentatie van bijlage IV in dezelfde pull request verandert als de code die ze beschrijft.

Fase 3: scan vóór de release

Een volledige scan van de releasekandidaat.

  • Volledige scan: Een complete code- en documentscan. De documentscan ondersteunt acht talen: EN, DE, FR, IT, ES, NL, PL en PT.
  • Conceptdossier: Scanara maakt conceptdocumenten volgens bijlage IV en bijlage V op basis van uw gegevens en beoordelingsantwoorden. Automatisch invullen gebeurt gedeeltelijk; de rest schrijft en controleert u zelf.
  • Bewijsmomentopname: Bewaar het scanrapport bij de releasevermelding, zodat u kunt aantonen wat wanneer is gecontroleerd.

Hoe de GitHub merge gate van Scanara werkt

Scanara ontvangt GitHub-pull-requestgebeurtenissen, scant de wijziging en meldt het resultaat als GitHub check run. In de alleen-rapportagemodus wordt een mislukte controle als neutraal gemeld. In blokkerende modus mislukt de controle.

De merge gate werkt alleen met GitHub. Geplande scans zijn nog niet beschikbaar; scans draaien op verzoek en bij pull requests.

Wat de scans controleren en waar ze ophouden

De dekking is gedeeltelijk. In de momentopname van 24 augustus 2026 hebben 77 van de 174 in kaart gebrachte verplichtingen coderegels, verspreid over 43 artikelen, en 23 hebben documentregels, verspreid over 23 artikelen. De indeling dateert van vóór de wijzigingen door Verordening (EU) 2026/1744, bijvoorbeeld de artikelen 4a, 60a en 75a tot en met 75d. De overige verplichtingen vragen beoordelingen en menselijk werk.

Coderegels

  • Artikel 5: verboden praktijken

    Regels markeren codepatronen die kunnen wijzen op een verboden praktijk. Of een praktijk verboden is, hangt af van doel en context, die de code niet toont.

  • Artikel 9: risicobeheer

    Regels markeren AI-beslispunten zonder herkenbare code voor risicobeoordeling of validatie.

  • Artikel 10: data en datagovernance

    Regels markeren trainingspipelines zonder herkenbare datakwaliteitscontroles.

  • Artikel 12: registratie

    Regels markeren AI-bewerkingen zonder herkenbare logging.

  • Artikel 14: menselijk toezicht

    Regels markeren beslispaden zonder herkenbaar punt voor menselijk ingrijpen, zoals een override of een stopprocedure.

  • Artikel 15: nauwkeurigheid en robuustheid

    Regels markeren ontbrekende modelvalidatie en ontbrekende nauwkeurigheidsmetrieken.

Documentregels

  • Onderdelen van de technische documentatie (artikel 11)

    De regels van Scanara bepalen acht verplichte onderdelen van de technische documentatie, gebaseerd op bijlage IV, en controleren of ze aanwezig zijn. Ze controleren of inhoud aanwezig is, niet of ze goed is.

  • Gebruiksaanwijzing (artikel 13)

    Controleert of de gebruiksaanwijzing bestaat en de vereiste onderdelen bevat.

  • EU-conformiteitsverklaring

    Controleert of de verklaring de in bijlage V genoemde elementen bevat.

  • Acht talen

    De documentscan ondersteunt EN, DE, FR, IT, ES, NL, PL en PT.

Implementatiechecklist

  • Voeg een code- en documentscan toe aan de pull-requestworkflow.
  • Begin in alleen-rapportagemodus en beoordeel de bevindingen.
  • Stel drempels in voor kritieke en hoge bevindingen en schakel dan over op blokkerende modus.
  • Eis menselijke beoordeling van elke bevinding die artikel 5 of artikel 14 raakt.
  • Bewaar het scanrapport bij elke releasevermelding.
  • Markeer wijzigingen aan model, trainingsdata of beoogd doel ter beoordeling als mogelijke substantiële wijzigingen (artikel 43(4)).
  • Voer vóór elke release de volledige scan opnieuw uit en werk de documentatie van bijlage IV bij.
  • Houd de technische documentatie in de repository naast de code en werk haar bij in dezelfde pull request.

Uitzonderingen, oudere systemen en maxima voor boetes

De verordening is niet van toepassing op AI-systemen die uitsluitend voor militaire doeleinden, defensie of nationale veiligheid worden gebruikt (artikel 2(3)). Ze is niet van toepassing op AI-systemen die specifiek en uitsluitend voor wetenschappelijk onderzoek en wetenschappelijke ontwikkeling zijn ontwikkeld en in gebruik gesteld (artikel 2(6)), noch op onderzoek, testen of ontwikkeling vóór het in de handel brengen of in gebruik stellen, behalve testen onder reële omstandigheden (artikel 2(8)). Systemen onder vrije en opensourcelicenties zijn uitgezonderd, tenzij ze als hoogrisicosystemen in de handel worden gebracht of in gebruik worden gesteld of onder artikel 5 of 50 vallen (artikel 2(12)). Natuurlijke personen die een systeem in een zuiver persoonlijke niet-beroepsmatige activiteit gebruiken, zijn niet als gebruiksverantwoordelijke gebonden (artikel 2(10)). Voor hoogrisicosystemen die verband houden met producten onder wetgeving uit bijlage I, afdeling B, zoals motorvoertuigen, luchtvaart, spoorwegen, scheepsuitrusting, landbouwvoertuigen en machines, gelden alleen artikel 6(1), artikel 60a en de artikelen 102 tot en met 112. De artikelen 57 tot en met 59 gelden alleen voor zover die wetgeving de vereisten overneemt (artikel 2(2)).

Hoogrisicosystemen die vóór de toepassingsdatum in de handel zijn gebracht of in gebruik zijn gesteld, vallen er pas onder na ingrijpende ontwerpwijzigingen. In elk geval moeten aanbieders en gebruiksverantwoordelijken van hoogrisico-AI-systemen die bedoeld zijn om door overheidsinstanties te worden gebruikt, uiterlijk 2 augustus 2030 de nodige stappen ondernemen om te voldoen (artikel 111(2)).

Voor mkb-bedrijven geldt per boete het laagste percentage of bedrag als maximum (artikel 99(6)). Voor kleine midcapondernemingen (artikel 3, punt 14b) geldt hetzelfde maximum voor boetes uit artikel 99, leden 4 en 5 (artikel 99(6a)). De categorie van 15 miljoen EUR omvat ook de verplichtingen van aanbieders en marktdeelnemers uit artikel 25, leden 2 en 4 (artikel 99(4), punt da)).

Lees verder: audittrails, regelgebaseerd scannen en technische documentatie

Scanara bereidt bewijs voor vanuit uw repositories

Scanara leest uw gekoppelde GitHub-repositories en voert regelgebaseerde scans uit op gangbare AI- en machine-learningpatronen. Niet-standaardcode kan het missen. Daarnaast genereert het conceptdocumentatie op basis van sjablonen en uw antwoorden in de beoordelingen, als bewijs voor uw compliancewerk. De indeling bepaalt u zelf.