AI-verordening SaaS: ben je provider, deployer, of allebei?

Nederlandse SaaS-bedrijven zitten in een eigenaardig gat als het om de AI-verordening SaaS gaat. Je bouwt software voor anderen, maar gebruikt zelf ook AI-tools van derden. Ben je dan provider, deployer, of gewoon in de problemen?

Dit is precies de vraag die compliance officers bij SaaS-bedrijven het meest stellen. En het antwoord heeft directe gevolgen voor je documentatieverplichtingen, je aansprakelijkheid, en de boetes die je riskeert.

Kijk, laten we het concreet maken.

# Wat zegt de AI-verordening over providers en deployers?

De AI-verordening maakt een scherp onderscheid tussen twee rollen.

Een provider is een organisatie die een AI-systeem ontwikkelt of laat ontwikkelen, met de bedoeling dit op de markt te brengen of in gebruik te stellen onder eigen naam of handelsmerk. Je bouwt iets en zet het op de markt.

Een deployer is een organisatie die een AI-systeem onder eigen verantwoordelijkheid in gebruik neemt, voor een specifiek doel. Je gebruikt iets wat een ander heeft gebouwd.

Dit staat in Artikel 3 van de verordening, de definities. Lid 3 voor provider, lid 4 voor deployer. Simpel genoeg. Totdat je een SaaS-bedrijf bent.

# Het probleem met SaaS

Een typisch Nederlands SaaS-bedrijf ziet er zo uit: je levert een platform aan klanten, je hebt zelf ook een backoffice vol AI-tools, en ergens in je product zit een AI-functie die je hebt gebouwd op een foundation model van OpenAI, Anthropic, of een Europese aanbieder.

Je bent op dat moment:

• Provider van het AI-systeem dat je aan je klanten levert
• Deployer van het foundation model of de AI-API die je gebruikt om dat systeem te bouwen
• Mogelijk ook deployer van de interne HR-tool met AI-functionaliteit die je voor je eigen mensen gebruikt

Drie rollen tegelijk is niet uitzonderlijk. Het is de norm.

En elke rol brengt andere verplichtingen met zich mee.

# Verplichtingen als provider

Als je AI-systemen levert aan klanten, val je als provider onder Artikel 16 van de AI-verordening. De exacte verplichtingen hangen af van het risiconiveau van jouw systeem.

Valt jouw systeem in de categorie hoog-risico, dan is de lijst lang: conformiteitsbeoordeling, technische documentatie, registratie in de EU-database, CE-markering, en een postmarkt-monitoringsysteem. Bijlage III bevat de volledige lijst van hoog-risico-toepassingen, denk aan systemen voor werving, kredietverstrekking, of onderwijs.

Maar ook buiten hoog-risico heb je verplichtingen. Artikel 50 schrijft voor dat systemen die tekst, audio, of afbeeldingen genereren, dit transparant moeten maken aan de gebruiker. Bouw je een chatbot of AI-schrijfassistent in je SaaS-product? Dan moet de eindgebruiker weten dat hij met AI praat.

Een punt dat SaaS-bedrijven vaak missen: als jij een AI-component bouwt op een foundation model, en jij die component op de markt brengt onder jouw naam, ben jij de provider. Niet OpenAI. Niet Google. Jij. De verantwoordelijkheid voor het eindproduct ligt bij degene die het onder eigen naam op de markt zet.

# Verplichtingen als deployer

Als deployer van een hoog-risico AI-systeem loopt het via Artikel 26. De zes verplichtingen die daar staan zijn concreet:

1. Technische en organisatorische maatregelen nemen om het systeem te gebruiken zoals de provider bedoeld heeft
2. Zorgen dat de mensen die het systeem bedienen, voldoende gekwalificeerd zijn
3. Menselijk toezicht instellen en daadwerkelijk uitvoeren
4. Inputdata monitoren op relevantie voor het bedoelde doel
5. Incidenten rapporteren aan de provider en soms direct aan de toezichthouder
6. Bij hoog-risico gebruik in bepaalde sectoren: een Fundamental Rights Impact Assessment uitvoeren

Dit laatste, de FRIA of grondrechten-impactbeoordeling, staat in Artikel 27. Je hoeft dit niet als je een kleine onderneming bent die een hoog-risico systeem gebruikt voor intern beheer, maar zodra je ermee beslissingen neemt over mensen, word je toch snel relevant.

Als deployer van AI die je intern inzet voor HR-beslissingen, prestatiebeoordeling, of werving, sta je in hoog-risico-territorium. Bijlage III, punt 4, is hier de referentie.

# Concrete scenario's voor SaaS-bedrijven

Scenario 1: HR-tech SaaS Je levert een applicant tracking system met een AI-scoring-component aan klanten. Jij hebt die component gebouwd op een taalmodel. Voor jouw klanten ben je de provider van een hoog-risico systeem (werving valt onder Bijlage III). Je moet conformiteitsdocumentatie leveren, transparantie bieden, en je klanten informeren over wat ze als deployer moeten doen. Gebruik je intern ook je eigen tool voor je eigen HR? Dan ben je ook deployer.

Scenario 2: Finance SaaS Je bouwt een boekhoudplatform met een AI-module die afwijkingen detecteert. Detectie van fraude of kredietrisico valt mogelijk ook onder hoog-risico. Maar een eenvoudige categorie-suggestie voor bonnetjes waarschijnlijk niet. Het onderscheid zit hem in de vraag: neemt het systeem of ondersteunt het een beslissing die significante impact heeft op een persoon?

Scenario 3: Productiviteits-SaaS met AI-assistent Je integreert een chatbot in je project management tool. De chatbot genereert tekst. Je bent provider van een AI-systeem met een transparantieverplichting op grond van Artikel 50. Geen hoog-risico, maar wel verplichtingen. En je bent deployer van de onderliggende API.

Scenario 4: Interne AI-tools Je gebruikt zelf Copilot voor je developers en een AI-tool voor het samenvatten van supporttickets. Hier ben je puur deployer. Geen hoog-risico als je er geen beslissingen over medewerkers mee neemt. Maar zodra je AI inzet bij prestatiereviews of verzuimanalyse, schuif je het hoog-risico-kader in.

# De dubbele-provider-uitzondering

Er is één geval waar een deployer provider wordt, en SaaS-bedrijven lopen er regelmatig tegenaan. Artikel 25 regelt dit: als je als deployer een substantiële aanpassing maakt aan een AI-systeem, of het voor een ander doel gaat gebruiken dan waarvoor het is ontworpen, word je zelf provider.

Koop je een generiek AI-component, bouw je er een eigen laag op, en breng je het onder jouw naam op de markt? Dan heeft de originele aanbieder zijn handen gewassen. De verplichtingen zijn van jou.

Dit is geen academische nuance. Dit is waarom SaaS-bedrijven die hun product bouwen op foundation models écht hun rol moeten begrijpen voordat ze contracten afsluiten met enterprise-klanten.

# Stappenplan: breng je rollen in kaart

De eerste stap is altijd inventarisatie. Maak een lijst van alle AI-systemen in je organisatie, opgesplitst in twee categorieën:

Wat lever je aan klanten? Per AI-component in je product: wat doet het, wie gebruikt het, voor welk doel, en kan het significante impact hebben op personen? Zet dit naast Bijlage III. Als er overlap is, ben je waarschijnlijk provider van een hoog-risico systeem.

Wat gebruik je intern? Per tool: voor welk proces, wie bedient het, worden er beslissingen mee genomen over mensen? HR, werving, prestatiebeheer zijn de alarmbellen. Maar ook klantselectie, kredietbeoordeling, en veiligheidssystemen.

Vanuit die inventarisatie kun je bepalen welke verplichtingen op jou rusten. Technische documentatie voor je eigen producten, een FRIA voor intern hoog-risico gebruik, en beleid voor menselijk toezicht in beide gevallen.

Eerlijk gezegd is de inventarisatie het werk. De rest is uitvoering.

# Wanneer begint dit te tellen?

De AI-verordening is op 1 augustus 2024 in werking getreden. De verplichtingen voor hoog-risico systemen gelden volledig per augustus 2026. Verboden AI-praktijken waren al van kracht per februari 2025. Transparantieverplichtingen zoals Artikel 50 gaan in per augustus 2026.

Voor SaaS-bedrijven die nu enterprise-contracten afsluiten: klanten vragen al naar compliance. De deadline is reëel, maar je hebt nog ruimte om dit goed te doen. Niet door te wachten, maar door nu je rollen helder te hebben.

Weet je nog niet zeker of jij als provider, deployer, of allebei valt? De gratis 2-minuten compliance-check op comply.khairos.ai geeft je direct een eerste richtlijn op basis van jouw specifieke situatie.