AI Act voor IT-dienstverleners en MSP's: provider of deployer?

Voor Nederlandse IT-dienstverleners, Managed Service Providers (MSP's) en systeemintegrators is de EU AI Act een rol-gedreven wet. De zwaarte van uw verplichtingen hangt vrijwel volledig af van welke rol u inneemt: provider, deployer, importer of distributor. Een verkeerde inschatting kan u onverwacht hoge documentatieplichten, certificeringen en aansprakelijkheid opleveren. In deze gids leggen we per situatie uit welke rol u heeft, wat u contractueel moet regelen en hoe u uw klanten ondersteunt bij hun eigen naleving.

Wat doen IT-dienstverleners en MSP's met AI in 2026?

De Nederlandse MSP-markt heeft de afgelopen twee jaar AI breed omarmd. De vier dominante inzetgebieden:

• Eigen SaaS met AI, een MSP die een eigen dashboard of klantportaal aanbiedt waarin AI is verwerkt (automatische ticketclassificatie, voorspellend onderhoud, anomaliedetectie). Hier loopt u snel risico om als provider te worden aangemerkt.
• GPAI-copilots, het uitrollen van Microsoft 365 Copilot, GitHub Copilot, Google Workspace AI of vergelijkbare oplossingen bij klanten. U bent dan in beginsel deployer voor uw eigen gebruik en distributor of importer richting klanten.
• Integratie van externe AI, koppelingen tussen een klantsysteem en bijvoorbeeld OpenAI, Anthropic of een specialistische vertical-AI. De rol hangt af van wie de API-credentials beheert en wie de prompts en outputs configureert.
• Automated security tools, EDR, SIEM, SOAR en helpdesk-AI met machine learning. Hier loopt de AI Act-vraag parallel aan NIS2-verplichtingen voor essentiele entiteiten.

Voor elke inzetcategorie moet u afzonderlijk bepalen welke rol u in de keten vervult. Voor meer context over de keten leest u onze gids conformiteitsbeoordeling onder de AI Act.

Rolbepaling: provider versus deployer onder de AI Act

De AI Act definieert vier hoofdrollen. Voor MSP's zijn provider en deployer veruit het belangrijkst.

Provider

U ontwikkelt of laat ontwikkelen een AI-systeem, en u brengt dat op de markt of in gebruik onder uw eigen naam of handelsmerk. Provider-verplichtingen zijn de zwaarste: conformiteitsbeoordeling, technische documentatie, kwaliteitsmanagementsysteem, post-market monitoring, registratie in de EU-database voor hoog-risico systemen en (waar relevant) CE-markering.

Deployer

U zet onder eigen verantwoordelijkheid een AI-systeem in voor uw bedrijfsdoeleinden. Deployer-verplichtingen zijn aanzienlijk lichter: gebruik volgens instructies van de provider, AI-geletterdheid van medewerkers, eventueel een FRIA als het hoog-risico AI betreft, en passende menselijke controle. Lees ook onze gids over artikel 26 en deployer-verplichtingen.

De val van artikel 25

Artikel 25 bepaalt drie situaties waarin een deployer of distributor zelf provider wordt:

• U brengt uw eigen naam of merk aan op een bestaand AI-systeem (white-label).
• U past een hoog-risico AI-systeem substantieel aan, waardoor het werkelijk anders functioneert.
• U gebruikt een AI-systeem voor een andere bestemming dan waarvoor de oorspronkelijke provider het in de markt heeft gezet.

Concreet voorbeeld: u koopt een sectorale AI-tool voor patiententriage en herlabelt deze onder uw eigen MSP-naam voor verzekeraars. U bent dan provider van een hoog-risico systeem met alle bijbehorende zwaarte. Veel MSP's onderschatten dit.

Importer en distributor in de AI Act

Voor partijen die AI-systemen van buiten de EU doorgeven gelden specifieke rollen:

• Importer, u brengt een AI-systeem van een leverancier buiten de EU op de Uniemarkt. U moet controleren dat de provider de conformiteitsbeoordeling heeft uitgevoerd, de technische documentatie beschikbaar is en de CE-markering aanwezig is. Bij twijfel mag u het systeem niet op de markt brengen.
• Distributor, u verkoopt of levert een AI-systeem dat al op de markt is. Lichter dan importer, maar u moet wel verifieren dat de basisformaliteiten (CE, handleiding, contactinformatie van provider en importer) in orde zijn.

Voor Nederlandse MSP's komt de importer-rol vaak voor bij Amerikaanse of Aziatische AI-tools die u contractueel of via OEM-afspraken naar Europese klanten brengt. De rol is beperkter dan die van provider, maar zeker niet symbolisch.

Wanneer wordt een MSP provider?

Drie veelvoorkomende scenario's waarin een MSP per ongeluk provider wordt:

1. AI als white-label, u koopt een AI-platform in, herlabelt het onder uw MSP-merknaam en levert het door aan klanten. Onmiddellijk provider.
2. Klantspecifieke fine-tuning, u traint een GPAI-model of een vertical-AI bij voor een specifieke klantcase. Of dit substantieel is, hangt af van de aard van de aanpassing. Een prompt-bibliotheek doorgaans niet, een werkelijk gefinetuned model met andere gedragingen vrijwel altijd wel.
3. Materiele wijzigingen, het wijzigen van een AI-systeem op een manier die het bedoelde gebruik, het risicoprofiel of de prestaties significant verandert. Bijvoorbeeld het uitbreiden van een chatbot naar nieuwe taalgebieden of nieuwe data-domeinen.

Contractuele clausules tussen MSP en eindklant

De rolverdeling tussen MSP en klant moet in elk contract expliciet zijn. Acht clausules die in iedere AI-MSP-overeenkomst horen:

• AI Act-rolverdeling, expliciet vastleggen wie provider, deployer, importer of distributor is voor welk systeem of welke component.
• Data Processing Agreement (DPA), een aparte AVG-bijlage die ook AI-specifieke verwerkingen behandelt (training, fine-tune, prompt-logging, retentie).
• Aansprakelijkheid voor output, helder wie verantwoordelijk is voor hallucinaties, foute aanbevelingen of bias-incidenten, en welke uitsluitingen of caps gelden.
• Audit rights, het recht van de klant om jaarlijks de AI-governance, logging, modelwijzigingen en testresultaten in te zien (al dan niet via een onafhankelijke derde).
• IP-clausule, eigendom van prompts, fine-tunes, embeddings en outputs. Wie mag wat hergebruiken? Mag de MSP geanonimiseerd leren van klantdata?
• Sub-processors en doorgifte, een actueel overzicht van AI-leveranciers waar de MSP gebruik van maakt, inclusief locaties (EU/VS/elders) en wijzigingsbeleid.
• Transparantie over modeltraining, of klantdata wel of niet wordt gebruikt voor modeltraining en hoe de klant dat kan blokkeren.
• Exit-bepalingen, hoe data, fine-tunes en logging worden teruggegeven of vernietigd na einde overeenkomst, en binnen welke termijn.

Cybersecurity AI-tools: hoog-risico of niet?

Veel MSP's vragen zich af of hun security-stack onder Bijlage III valt. In de regel is dat niet het geval. Bijlage III somt de hoog-risico categorieen op (kritieke infrastructuur, onderwijs, werkgelegenheid, essentiele diensten, wetshandhaving, migratie, justitie). Klassieke SIEM-, EDR-, MDM- en SOAR-tools vallen daar niet onder zolang ze worden ingezet voor algemene IT-beveiliging.

Twee kanttekeningen:

• NIS2 voor essentiele entiteiten, voor klanten in energie, drinkwater, zorg, financien, transport en digitale infrastructuur gelden onder NIS2 strenge eisen rond risicoanalyse, supply chain security en incident reporting. Onze gids AI Act vs NIS2 behandelt de overlap in detail.
• Toegangscontrole tot essentiele diensten, als uw AI bepaalt of een burger of klant toegang krijgt tot een essentiele dienst, kan Bijlage III alsnog van toepassing zijn. Denk aan AI-gebaseerde fraudedetectie bij een betaalsysteem.

AI in MDM, SIEM en helpdesk-AI: praktische naleving

Voor de dagelijkse MSP-praktijk gelden vier basisregels, ook bij niet-hoog-risico AI:

• Documenteer welke AI-componenten in welke tool zitten en welke functie ze hebben.
• Houd een korte beoordeling bij van de provider: heeft de leverancier een AI-act-statement, een DPA, een privacy en security whitepaper?
• Train uw eigen techneuten in AI-geletterdheid (artikel 4). Lees onze gids AI-geletterdheid in de praktijk.
• Bouw periodieke evaluatie in: doet het AI-systeem nog wat het moet doen, ontstaat er onbedoelde drift, zijn er onverwachte effecten zoals false positives in security-alerts?

8-punts checklist voor MSP's

Hoe ondersteun je klanten bij hun naleving?

MSP's worden in 2026 steeds vaker gezien als de natuurlijke nalevingspartner van het MKB. Drie diensten zijn snel op te zetten en commercieel relevant:

• Transparantie en uitleg, bied klanten standaard een overzicht van welke AI in hun stack zit, met welk doel, welke leverancier en welk risiconiveau. Dit is direct bruikbaar voor het AI-register van de klant.
• Documentatie-ondersteuning, lever templates voor FRIA's, gebruikershandleidingen en gebruikersinformatie. Als deployer-klant moet de eindorganisatie deze hebben, maar weet vaak niet hoe te beginnen.
• Audit-support, faciliteer audits door toezichthouders of certificeerders met vaste logging-exporten, change-history en testresultaten. Goede MSP's verkopen dit als premium-dienst.

Zie ook onze uitleg over ISO 42001 als governance-framework voor wie de standaardisatie volledig wil omarmen.