Wanneer general-purpose AI-modellen van toepassing zijn en wat daarna te doen

General-purpose AI-modellen zijn relevant voor een SaaS-team wanneer het bedrijf een model levert, integreert, deployt, fine-tunet, configureert of er materieel van afhankelijk is. De eerste vraag is niet of het bedrijf een model lab is. De vraag is waar modellen zitten in product, vendor stack, interne workflows, klantbeloftes en bewijs.

Onder de EU AI Act staan de belangrijkste verplichtingen in hoofdstuk V. Artikel 53 vraagt technische documentatie, informatie voor downstream providers, copyrightbeleid en publieke samenvatting van trainingscontent. Artikel 55 voegt verplichtingen toe voor modellen met systeemrisico. Artikel 51 legt de classificatie uit.

Wanneer het praktisch geldt

Het geldt wanneer product of proces afhankelijk is van een algemeen model: API, copilot, documentsamenvatting, aanbevelingen, classificatie, supportantwoorden, zoekfunctie, tekst- of codegeneratie, of klantconfigureerbare workflows.

Het geldt ook intern. Support, sales, security of operations kunnen AI gebruiken op een manier die privacy-, security-, copyright-, klantvertrouwen- en rolmappingvragen oproept.

Wanneer het niet het hoofdonderwerp is

Bij laagrisico intern gebruik kan acceptable use, vertrouwelijkheid en security belangrijker zijn dan een volledige modelprovideranalyse. Maar een "niet van toepassing" conclusie moet worden vastgelegd. Een kleine pilot kan productafhankelijkheid worden.

Stap 1: modelinventaris

Maak een lijst van hosted APIs, open source, fine-tuning, vendor features, interne tools, copilots, support assistants, analytics en klantconfigureerbare workflows.

Leg per item model, provider, versie, hosting, use case, owner, data, klantblootstelling, belangrijke outputs, fine-tuning, klantconfiguratie en vendordocumentatie vast.

Stap 2: rollenkaart

Bepaal of het bedrijf modelprovider, downstream provider van een AI-systeem, deployer, gebruiker van een vendorfunctie of modelmodifier is. Die rol bepaalt verplichtingen en bewijsverwachtingen.

De rollenkaart hoort in product intake, vendor review, security, privacy, architecture, launch readiness en customer trust.

Stap 3: providerbewijs

Bij een extern model verzamel je bewijs vroeg. Vraag naar mogelijkheden, beperkingen, toegestane uses, versies, change notices, security, evaluation, retention, gebruik van data voor training, copyright, trainingssamenvatting en incidenten.

Als de provider systeemrisico noemt, vraag welk artikel 55-bewijs beschikbaar is en welke wijzigingen notificatie vereisen.

Stap 4: reviewpad

Niet elk gebruik vraagt dezelfde review. Licht voor goedgekeurde interne productiviteit. Standaard voor vendor features, copilots, support, analytics of klantzichtbare outputs. Versterkt voor gevoelige data, gereguleerde klanten, fine-tuning, kritieke afhankelijkheid of klantconfiguratie.

Elke review eindigt met approved, approved with conditions, blocked of more facts needed. Voorwaarden hebben owner en datum nodig.

Stap 5: wijzigingstriggers

Beslissingen verouderen snel. Nieuwe provider, nieuwe versie, nieuwe feature, nieuwe data, gereguleerde klant, fine-tuning, hostingwijziging, vendor policy, incident of belangrijk gedragverschil moet review heropenen.

FAQ

Waarvoor dient deze governance?

Om te weten waar modellen het bedrijf raken, welke rol het bedrijf heeft, welk bewijs bestaat, welke controles gelden en wanneer review opnieuw nodig is.

Wanneer geldt dit voor SaaS?

Wanneer het team een model levert, integreert, deployt, configureert, fine-tunet of ervan afhankelijk is in product, workflow, vendorrelatie, klantbelofte of enterprise review.

Wat documenteer je eerst?

Modelinventaris en rollenkaart. Daarna providerbewijs, versie, use case, data, klanten, security, privacy, copyright, beperkingen, monitoring, changes en goedgekeurde antwoorden.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 51, Article 53, Article 55, Article 56 and Article 113.