AI-model kopen ontslaat je niet van EU AI Act-plichten

U bent verantwoordelijk voor de classificatie en governance van elk AI-systeem dat u implementeert, ongeacht of u het model hebt gekocht. Het kopen van een conform model ontslaat u niet van die plicht.

Een analyse van 4 november 2026 van hoe aankoop van een conform AI-model uw EU AI Act-verplichtingen niet opheft stelt dat de verplichting ligt bij de manier waarop u het model inzet, welke beslissingen het ondersteunt en of wijzigingen van doel u in de rol van aanbieder plaatsen. Een organisatie die een ondersteuningsagent bouwt rond een gekocht model kan zich als aanbieder van een hoog-risicosysteem kwalificeren als het systeem ingrijpende beslissingen ondersteunt of als het doel verandert. In onze analyse is de sterkste waarborg tegen onopgemerkte rolverschuiving een dossier voor wijzigingsbeheer dat naast uw classificatiedossier wordt bijgehouden, met daarin het oorspronkelijke doel, elke wijziging, validatieresultaten, menselijke beheersmaatregelen en de goedkeuringsbeslissing.

Welke risiconiveaus bepalen uw verplichting?

De EU AI Act werkt met vier risiconiveaus, elk met verschillende vereisten. Onaanvaardbaar risico betreft praktijken die de wetgeving verbiedt—manipulatie, social scoring, bepaalde vormen van biometrische identificatie—in plaats van systemen die na aanvullende documentatie kunnen worden voortgezet. Hoog risico omvat systemen die onder een vermeld gebruiksgeval vallen of onder gereguleerde producten, maar niet elke toepassing in een ziekenhuis is automatisch een medisch hulpmiddel met hoog risico, en niet elk administratief hulpmiddel van een werkgever vervult een werkgelegenheidsfunctie met hoog risico. Beperkt risico markeert systemen met transparantieverplichting op basis van triggers, maar die label kan verbergen dat een hoog-risicosysteem ook rechtstreeks met mensen interageert of synthetische inhoud genereert. Minimaal risico betekent niet de afwezigheid van governance; AI-geletterdheid en andere toepasselijke wetten kunnen relevant blijven.

Hoe classificeert u uw implementatie?

De onderliggende technologie beantwoordt de classificatievraag niet. Hetzelfde model kan materieel verschillende regelgevende uitkomsten ondersteunen afhankelijk van doel en context. Begin met drie concrete vragen: wat is het beoogde doel van het systeem, welke beslissingen ondersteunt het, en wie draagt verantwoordelijkheid voor die beslissingen? Leg voor elk systeem vast: de verplichting, de verantwoordelijke operator, de juridische bron, de toepasselijke overgang en uw interne gereedschapsdatum. Classificeer de geïmplementeerde functie en het beoogde doel, en leg vervolgens de redenen voor die uitkomst vast. Een label van verificatie of beslissingsondersteuning maakt een ingrijpende workflow niet automatisch laag-risico. Een nuttige interne toets is of uw team een beknopt classificatieformulier kan opstellen dat door de onderliggende analyse wordt onderbouwd.

Welke rollen en wijzigingen bepalen uw conformiteitsverplichting?

De rol ligt niet vast door aankoop. Onder artikel 25 van de AI Act kan een distributeur, importeur of derde partij de aanbieder van een hoog-risicosysteem worden door rebranding, substantiële wijziging of een verandering van het beoogde doel die het systeem hoog-risico maakt. Een aanbieder ontwikkelt een systeem of brengt het onder eigen naam op de markt; een deployer gebruikt het onder zijn gezag. Niet elke retrieval-augmented prompt, workflow-integratie of gecontroleerde bewerking vormt een substantiële wijziging. Het antwoord hangt af van de juridische toets, de oorspronkelijke beoordeling en de feiten.

Een verdedigbaar wijzigingsbeheer omvat:

1. Registreer het oorspronkelijke doel en de beoordeling — leg vast welk doel de classificatie rechtvaardigt en welke vereisten van toepassing zijn.
2. Documenteer elke wijziging van doel, model of workflow — beschrijf wat verandert en waarom, met datering en eigenaar.
3. Voer validatie uit voor wijzigingen — test of de beheersmaatregelen nog steeds werken onder het nieuwe doel.
4. Leg menselijke beheersmaatregelen vast — beschrijf hoe toezicht, escalatie en interventie werken.
5. Goedkeuren of escaleren — besluit of de wijziging onder dezelfde classificatie kan blijven of herbeoordeling vereist.
6. Bewaar het dossier — houd het wijzigingsdossier naast uw classificatiedossier.

Welke documentatie en bewijsspoor moet u behouden?

De AI Act vereist dat aanbieders gespecificeerde documentatie tien jaar na ingebruikname bewaren, en door de aanbieder beheerde automatische logs gedurende ten minste zes maanden. Wijs elke beheersmaatregel een met naam genoemde eigenaar, versie en datum toe. Voor risicomanagement koppelt u een gevaar aan de mitigatie- en validatieresultaten ervan; voor toezicht verbindt u de schriftelijke procedure aan een beschikbaar interventiemechanisme en bewijs van het gebruik ervan. Datagovernance-dossiers zouden relevante voorbereidingskeuzes en beperkingen moeten toelichten, in plaats van slechts datasets op te sommen. Technische documentatie zou een beoordelaar in staat moeten stellen het systeem te begrijpen zonder het ontwerp te reconstrueren.

Voor ingrijpende runs kan een praktisch bewijsspoor omvatten:

• Onveranderbare run-identificaties — unieke identifiers voor elke uitvoering, met datum en tijd.
• Metadata over modelversie en prompt — welk model, welke versie, welke invoer, welke parameters.
• Opgehaalde bronnen en context — welke documenten of gegevens het systeem gebruikte.
• Uitkomsten van beoordelaars en correcties — wie controleerde de output, wat werd aangepast, waarom.
• Toegangslogs en incidentregistraties — wie heeft het systeem gebruikt, wanneer, en welke problemen zijn opgetreden.

Pas toegangs- en bewaarmaatregelen toe op het spoor zelf, aangezien logs vertrouwelijk materiaal kunnen bevatten. De doorslaggevende toets is of het dossier aantoont dat beheersmaatregelen werken zoals ontworpen, inclusief tekortkomingen, interventies en correcties, in plaats van slechts aan te tonen dat beleidslijnen zijn goedgekeurd.

Welke conformiteitsbeoordeling moet u uitvoeren?

De beoordelingsroute volgt de wettelijke categorie en productcontext van het systeem, niet het door u geprefereerde certificeringsproces. Voor de meeste op zichzelf staande toepassingen met hoog risico draait de route om uw eigen gedocumenteerde beoordeling. Dat vereist nog steeds een samenhangend technisch dossier, een functionerend kwaliteitsmanagementsysteem en bewijs dat aan de toepasselijke vereisten is voldaan. Een interne goedkeuringsvergadering staat niet gelijk aan een conformiteitsbeoordeling. De verantwoordelijke ondertekenaar heeft een basis nodig voor de verklaring, inclusief onopgeloste beperkingen en de relatie tussen tests, controles en beoogd gebruik. Geharmoniseerde normen die in het Publicatieblad zijn gepubliceerd, kunnen een vermoeden van conformiteit ondersteunen uitsluitend voor de vereisten die zij dekken. ISO/IEC 42001 is een managementsysteemnorm; certificering daartegen stelt op zichzelf geen conformiteit met de systeemspecifieke vereisten van de AI Act vast.

Stel voordat u de route goedkeurt vast: wie ondertekent de verklaring, is een aangemelde instantie nodig, en welke normen blijven onopgelost. Coördineer die beslissing voor gereguleerde producten met uw productconformiteitsteam in plaats van een afzonderlijke, losstaande AI-goedkeuring te creëren.

Hoe handelt u upstream-documentatie en modelverplichtingen af?

Systeemtransparantie en upstream modelverplichtingen zijn afzonderlijke verantwoordelijkheden. Het koppelen van een model van een derde partij aan uw workflow draagt niet alle verantwoordelijkheid over aan de modelaanbieder. Een beleidsevaluatie zou zowel de interface die mensen tegenkomen als de upstream documentatie die voor u beschikbaar is moeten onderzoeken. De AI Act maakt onderscheid tussen het informeren van mensen dat zij met AI interacteren, machineleesbare markering van synthetische output, en openbaarmakingen door gebruiksverantwoordelijken voor gespecificeerde gegenereerde of gemanipuleerde inhoud. Een label op het scherm en technische outputmarkering vervullen verschillende functies; men mag niet aannemen dat het ene het andere vervangt.

Voor inkoop en integratie omvat een verdedigbaar documentatiepakket: de technische documentatie van de aanbieder, de EU-conformiteitsverklaring, auteursrechtbeleid, trainingsinhoudgegevens, en voor modellen met systeemrisico ook evaluatie- en risicobeoordelingsdocumenten. Documenteer voor een implementatiebeoordeling wat elke ontvanger ontvangt, in plaats van aan te nemen dat getransformeerde context elke privacyvraag wegneemt. Het vergelijken van output van onafhankelijke modellen kan professionele evaluatie ondersteunen, maar overeenstemming tussen meerdere modellen is geen conformiteitsbeoordeling, levert geen ontbrekende aanbiederdocumentatie op en stelt niet vast dat een antwoord juist is. De inkoopvraag is daarom specifiek: wat heeft elke upstream aanbieder gedocumenteerd, wat kunt u verifiëren, en wat blijft onbekend?

Tooling kan uw bewijsspoor ondersteunen, uw classificatie vastleggen en uw wijzigingsbeheer ordenen. Tooling bepaalt niet de juridische classificatie, vervangt geen conformiteitsbeoordeling en kan niet de professionele oordelen nemen die nodig zijn waar data of normen onzeker blijven. Waar tegenstrijdige standpunten bestaan, benoem de persoon die verantwoordelijk is voor de oplossing en stel de volgende beoordeling vast.